Michal Piotrowski reported the following validator assert:
hdd: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdd: set_drive_speed_status: error=0xb4 { AbortedCommand LastFailedSense=0x0b }
============================
[ BUG: illegal lock usage! ]
----------------------------
illegal {in-hardirq-W} -> {hardirq-on-W} usage.
hdparm/1821 [HC0[0]:SC0[0]:HE1:SE1] takes:
(ide_lock){++..}, at: [<c0268388>] ide_dump_opcode+0x13/0x9b
[...]
stack backtrace:
[<c0104513>] show_trace+0x1b/0x20
[<c01045f1>] dump_stack+0x1f/0x24
[<c013976c>] print_usage_bug+0x1a5/0x1b1
[<c0139e90>] mark_lock+0x2ca/0x4f7
[<c013aa96>] __lockdep_acquire+0x47e/0xaa4
[<c013b536>] lockdep_acquire+0x67/0x7f
[<c030552d>] _spin_lock+0x24/0x32
[<c0268388>] ide_dump_opcode+0x13/0x9b
[<c02688b6>] ide_dump_status+0x4a6/0x4cc
[<c0267ae6>] ide_config_drive_speed+0x32a/0x33a
[<c0262dc5>] piix_tune_chipset+0x2ed/0x2f8
[<c0262e31>] piix_config_drive_xfer_rate+0x61/0xb5
[<c0263a82>] set_using_dma+0x2f/0x60
[<c0263bee>] ide_write_setting+0x4a/0xc3
[<c02647ca>] generic_ide_ioctl+0x8a/0x47f
[<f886003a>] idecd_ioctl+0xfd/0x133 [ide_cd]
[<c01f1fff>] blkdev_driver_ioctl+0x4b/0x5f
[<c01f2783>] blkdev_ioctl+0x770/0x7bd
[<c017dc0d>] block_ioctl+0x1f/0x21
[<c0189353>] do_ioctl+0x27/0x6e
[<c0189604>] vfs_ioctl+0x26a/0x280
[<c0189667>] sys_ioctl+0x4d/0x7e
[<c0305ed2>] sysenter_past_esp+0x63/0xa1
in ide_dump_opcode() takes the ide_lock in an irq-unsafe manner, i.e. this
function expects to be called with irqs disabled. But
ide_dump_ata[pi]_status() doesnt do that - it enables interrupts specifically.
That is a no-no - what guarantees that another IDE port couldnt generate an
IDE interrupt while we are dumping this error? The fix is to turn the
irq-enabling in these functions into irq-disabling.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Remove the busproc from pdc202xx_old.c because:
- it handles the obsolete HDIO_TRISTATE_HWIF ioctl instead of the modern
HDIO_SET_BUSSTATE, so treats its argument wrong;
- I don't think that tristating both channels is good idea (probably can't
be done otherwise since there seems to be only single bit controlling this).
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The function ide_timing_compute() fails to *actually* take drive's
specified minimum PIO/DMA cycle times into account -- when doing this, it
calls ide_timing_merge() on the 'struct ide_timing' argument which contains
garbage at the moment, and then ultimately destroys the read cycle time by
quantizing the ide_timing[] entry, instead of copying from that entry to
the argument structure, and only then doing a merge/quantize.
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
During an STR resume cycle, the ide master disk times-out when there is
also a slave present (especially CD). Increasing the timeout in ide-io
from 10,000 to 100,000 fixes this problem.
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This bit us a few kernels ago, and for some reason never made it's way
upstream.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144743
Kernel panic - not syncing: drivers/ide/pci/piix.c:231:
spin_lock(drivers/ide/ide.c:c03cef28) already locked by driver/ide/ide-iops.c/1153.
Signed-off-by: Dave Jones <davej@redhat.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Dave Jones <davej@redhat.com>
Cc: Jens Axboe <axboe@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Remove a call to hwif->tuneproc() on the error path of
config_chipset_for_dma(), as its single caller
(pdc202xx_config_drive_xfer_rate()) will do the call in that case.
Signed-off-by: Tobias Oed <tobiasoed@hotmail.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
After the previous patch SIGNAL_GROUP_EXIT implies a pending SIGKILL, we
can remove this check from copy_process() because we already checked
!signal_pending().
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch optimizes zap_threads() for the case when there are no ->mm
users except the current's thread group. In that case we can avoid
'for_each_process()' loop.
It also adds a useful invariant: SIGNAL_GROUP_EXIT (if checked under
->siglock) always implies that all threads (except may be current) have
pending SIGKILL.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is a preparation for the next patch. No functional changes.
Basically, this patch moves '->flags & SIGNAL_GROUP_EXIT' check into
zap_threads(), and 'complete(vfork_done)' into coredump_wait outside of
->mmap_sem protected area.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch removes tasklist_lock from zap_threads().
This is safe wrt:
do_exit:
The caller holds mm->mmap_sem. This means that task which
shares the same ->mm can't pass exit_mm(), so it can't be
unhashed from init_task.tasks or ->thread_group lists.
fork:
None of sub-threads can fork after zap_process(leader). All
processes which were created before this point should be
visible to zap_threads() because copy_process() adds the new
process to the tail of init_task.tasks list, and ->siglock
lock/unlock provides a memory barrier.
de_thread:
It does list_replace_rcu(&leader->tasks, ¤t->tasks).
So zap_threads() will see either old or new leader, it does
not matter. However, it can change p->sighand, so we should
use lock_task_sighand() in zap_process().
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
With this patch zap_process() sets SIGNAL_GROUP_EXIT while sending SIGKILL to
the thread group. This means that a TASK_TRACED task
1. Will be awakened by signal_wake_up(1)
2. Can't sleep again via ptrace_notify()
3. Can't go to do_signal_stop() after return
from ptrace_stop() in get_signal_to_deliver()
So we can remove all ptrace related stuff from coredump path.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
With this patch a thread group is killed atomically under ->siglock. This is
faster because we can use sigaddset() instead of force_sig_info() and this is
used in further patches.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
zap_threads() iterates over all threads to find those ones which share
current->mm. All threads in the thread group share the same ->mm, so we can
skip entire thread group if it has another ->mm.
This patch shifts the killing of thread group into the newly added
zap_process() function. This looks as unnecessary complication, but it is
used in further patches.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We should keep the value of old_leader->tasks.next in de_thread, otherwise
we can't do for_each_process/do_each_thread without tasklist_lock held.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Below is a patch to add a new /proc/self/attr/sockcreate A process may write a
context into this interface and all subsequent sockets created will be labeled
with that context. This is the same idea as the fscreate interface where a
process can specify the label of a file about to be created. At this time one
envisioned user of this will be xinetd. It will be able to better label
sockets for the actual services. At this time all sockets take the label of
the creating process, so all xinitd sockets would just be labeled the same.
I tested this by creating a tcp sender and listener. The sender was able to
write to this new proc file and then create sockets with the specified label.
I am able to be sure the new label was used since the avc denial messages
kicked out by the kernel included both the new security permission
setsockcreate and all the socket denials were for the new label, not the label
of the running process.
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Try to make next_tid() a bit more readable and deletes unnecessary
"pid_alive(pos)" check.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
first_tid:
/* If nr exceeds the number of threads there is nothing todo */
if (nr) {
if (nr >= get_nr_threads(leader))
goto done;
}
This is not reliable: sub-threads can exit after this check, so the
'for' loop below can overlap and proc_task_readdir() can return an
already filldir'ed dirents.
for (; pos && pid_alive(pos); pos = next_thread(pos)) {
if (--nr > 0)
continue;
Off-by-one error, will return 'leader' when nr == 1.
This patch tries to fix these problems and simplify the code.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is just like my previous removal of tasklist_lock from first_tgid, and
next_tgid. It simply had to wait until it was rcu safe to walk the thread
list.
This should be the last instance of the tasklist_lock in proc. So user
processes should not be able to influence the tasklist lock hold times.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In process of getting proc_fd_access_allowed to work it has developed a few
warts. In particular the special case that always allows introspection and
the special case to allow inspection of kernel threads.
The special case for introspection is needed for /proc/self/mem.
The special case for kernel threads really should be overridable
by security modules.
So consolidate these checks into ptrace.c:may_attach().
The check to always allow introspection is trivial.
The check to allow access to kernel threads, and zombies is a little
trickier. mem_read and mem_write already verify an mm exists so it isn't
needed twice. proc_fd_access_allowed only doesn't want a check to verify
task->mm exits, s it prevents all access to kernel threads. So just move
the task->mm check into ptrace_attach where it is needed for practical
reasons.
I did a quick audit and none of the security modules in the kernel seem to
care if they are passed a task without an mm into security_ptrace. So the
above move should be safe and it allows security modules to come up with
more restrictive policy.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: James Morris <jmorris@namei.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Since 2.2 we have been doing a chroot check to see if it is appropriate to
return a read or follow one of these magic symlinks. The chroot check was
asking a question about the visibility of files to the calling process and
it was actually checking the destination process, and not the files
themselves. That test was clearly bogus.
In my first pass through I simply fixed the test to check the visibility of
the files themselves. That naive approach to fixing the permissions was
too strict and resulted in cases where a task could not even see all of
it's file descriptors.
What has disturbed me about relaxing this check is that file descriptors
are per-process private things, and they are occasionaly used a user space
capability tokens. Looking a little farther into the symlink path on /proc
I did find userid checks and a check for capability (CAP_DAC_OVERRIDE) so
there were permissions checking this.
But I was still concerned about privacy. Besides /proc there is only one
other way to find out this kind of information, and that is ptrace. ptrace
has been around for a long time and it has a well established security
model.
So after thinking about it I finally realized that the permission checks
that make sense are the permission checks applied to ptrace_attach. The
checks are simple per process, and won't cause nasty surprises for people
coming from less capable unices.
Unfortunately there is one case that the current ptrace_attach test does
not cover: Zombies and kernel threads. Single stepping those kinds of
processes is impossible. Being able to see which file descriptors are open
on these tasks is important to lsof, fuser and friends. So for these
special processes I made the rule you can't find out unless you have
CAP_SYS_PTRACE.
These proc permission checks should now conform to the principle of least
surprise. As well as using much less code to implement :)
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The code doesn't need to sleep to when making this check so I can just do the
comparison and not worry about the reference counts.
TODO: While looking at this I realized that my original cleanup did not push
the permission check far enough down into the stack. The call of
proc_check_dentry_visible needs to move out of the generic proc
readlink/follow link code and into the individual get_link instances.
Otherwise the shared resources checks are not quite correct (shared
files_struct does not require a shared fs_struct), and there are races with
unshare.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Incrementally update my proc-dont-lock-task_structs-indefinitely patches so
that they work with struct pid instead of struct task_ref.
Mostly this is a straight 1-1 substitution.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Every inode in /proc holds a reference to a struct task_struct. If a
directory or file is opened and remains open after the the task exits this
pinning continues. With 8K stacks on a 32bit machine the amount pinned per
file descriptor is about 10K.
Normally I would figure a reasonable per user process limit is about 100
processes. With 80 processes, with a 1000 file descriptors each I can trigger
the 00M killer on a 32bit kernel, because I have pinned about 800MB of useless
data.
This patch replaces the struct task_struct pointer with a pointer to a struct
task_ref which has a struct task_struct pointer. The so the pinning of dead
tasks does not happen.
The code now has to contend with the fact that the task may now exit at any
time. Which is a little but not muh more complicated.
With this change it takes about 1000 processes each opening up 1000 file
descriptors before I can trigger the OOM killer. Much better.
[mlp@google.com: task_mmu small fixes]
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Paul Jackson <pj@sgi.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Albert Cahalan <acahalan@gmail.com>
Signed-off-by: Prasanna Meda <mlp@google.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently in /proc at several different places we define buffers to hold a
process id, or a file descriptor . In most of them we use either a hard coded
number or a different define. Modify them all to use PROC_NUMBUF, so the code
has a chance of being maintained.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Like the bug Oleg spotted in first_tid there was also a small off by one
error in first_tgid, when a seek was done on the /proc directory. This
fixes that and changes the code structure to make it a little more obvious
what is going on.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Since we no longer need the tasklist_lock for get_task_struct the lookup
methods no longer need the tasklist_lock.
This just depends on my previous patch that makes get_task_struct() rcu
safe.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We don't need the tasklist_lock to safely iterate through processes
anymore.
This depends on my previous to task patches that make get_task_struct rcu
safe, and that make next_task() rcu safe. I haven't gotten
first_tid/next_tid yet only because next_thread is missing an
rcu_dereference.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There are a couple of problems this patch addresses.
- /proc/<tgid>/task currently does not work correctly if you stop reading
in the middle of a directory.
- /proc/ currently requires a full pass through the task list with
the tasklist lock held, to determine there are no more processes to read.
- The hand rolled integer to string conversion does not properly running
out of buffer space.
- We seem to be batching reading of pids from the tasklist without reason,
and complicating the logic of the code.
This patch addresses that by changing how tasks are processed. A
first_<task_type> function is built that handles restarts, and a
next_<task_type> function is built that just advances to the next task.
first_<task_type> when it detects a restart usually uses find_task_by_pid. If
that doesn't work because there has been a seek on the directory, or we have
already given a complete directory listing, it first checks the number tasks
of that type, and only if we are under that count does it walk through all of
the tasks to find the one we are interested in.
The code that fills in the directory is simpler because there is only a single
for loop.
The hand rolled integer to string conversion is replaced by snprintf which
should handle the the out of buffer case correctly.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
proc_lookup and task exiting are not synchronized, although some of the
previous code may have suggested that. Every time before we reuse a dentry
namei.c calls d_op->derevalidate which prevents us from reusing a stale dcache
entry. Unfortunately it does not prevent us from returning a stale dcache
entry. This race has been explicitly plugged in proc_pid_lookup but there is
nothing to confine it to just that proc lookup function.
So to prevent the race I call revalidate explictily in all of the proc lookup
functions after I call d_add, and report an error if the revalidate does not
succeed.
Years ago Al Viro did something similar but those changes got lost in the
churn.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
To keep the dcache from filling up with dead /proc entries we flush them on
process exit. However over the years that code has gotten hairy with a
dentry_pointer and a lock in task_struct and misdocumented as a correctness
feature.
I have rewritten this code to look and see if we have a corresponding entry in
the dcache and if so flush it on process exit. This removes the extra fields
in the task_struct and allows me to trivially handle the case of a
/proc/<tgid>/task/<pid> entry as well as the current /proc/<pid> entries.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
All of the functions for proc_maps_operations are already defined in
task_mmu.c so move the operations structure to keep the functionality
together.
Since task_nommu.c implements a dummy version of /proc/<pid>/maps give it a
simplified version of proc_maps_operations that it can modify to best suit its
needs.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Use getattr to get an accurate link count when needed. This is cheaper and
more accurate than trying to derive it by walking the thread list of a
process.
Especially as it happens when needed stat instead of at readdir time.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Long ago and far away in 2.2 we started checking to ensure the files we
displayed in /proc were visible to the current process. It was an
unsophisticated time and no one was worried about functions full of FIXMES in
a stable kernel. As time passed the function became sacred and was enshrined
in the shrine of how things have always been. The fixes came in but only to
keep the function working no one really remembering or documenting why we did
things that way.
The intent and the functionality make a lot of sense. Don't let /proc be an
access point for files a process can see no other way. The implementation
however is completely wrong.
We are currently checking the root directories of the two processes, we are
not checking the actual file descriptors themselves.
We are strangely checking with a permission method instead of just when we use
the data.
This patch fixes the logic to actually check the file descriptors and make a
note that implementing a permission method for this part of /proc almost
certainly indicates a bug in the reasoning.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The inode operations only exist to support the proc_permission function.
Currently mem_read and mem_write have all the same permission checks as
ptrace. The fs check makes no sense in this context, and we can trivially get
around it by calling ptrace.
So simply the code by killing the strange weird case.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
First we can access every /proc/<tgid>/task/<pid> directory as /proc/<pid> so
proc_task_permission is not usefully limiting visibility.
Second having related filesystems information should have nothing to do with
process visibility. kill does not implement any checks like that.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The sole renaming use of proc_inode.type is to discover the file descriptor
number, so just store the file descriptor number and don't wory about
processing this field. This removes any /proc limits on the maximum number of
file descriptors, and clears the path to make the hard coded /proc inode
numbers go away.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently in /proc if the task is dumpable all of files are owned by the tasks
effective users. Otherwise the files are owned by root. Unless it is the
/proc/<tgid>/ or /proc/<tgid>/task/<pid> directory in that case we always make
the directory owned by the effective user.
However the special case for directories is pointless except as a way to read
the effective user, because the permissions on both of those directories are
world readable, and executable.
/proc/<tgid>/status provides a much better way to read a processes effecitve
userid, so it is silly to try to provide that on the directory.
So this patch simplifies the code by removing a pointless special case and
gets us one step closer to being able to remove the hard coded /proc inode
numbers.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The removed fields are already set by proc_alloc_inode. Initializing them in
proc_alloc_inode implies they need it for proper cleanup. At least ei->pde
was not set on all paths making it look like proc_alloc_inode was buggy. So
just remove the redundant assignments.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We already call everything except do_proc_readlink outside of the BKL in
proc_pid_followlink, and there appears to be nothing in do_proc_readlink that
needs any special protection.
So remove this leftover from one of the BKL cleanup efforts.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I noticed recently that my CONFIG_CRYPTO_MD5 turned into a y again instead
of m. It turns out that CONFIG_NFSD_V4 is selecting it to be y even though
I've chosen to compile nfsd as a module.
In general when we have a bool sitting under a tristate it is better to
select things you need from the tristate rather than the bool since that
allows the things you select to be modules.
The following patch does it for nfsd.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Neil Brown <neilb@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add the IOCTLs of the Gigaset drivers to compat_ioctl.h in order to make
them available for 32 bit programs on 64 bit platforms. Please merge.
Signed-off-by: Hansjoerg Lipp <hjlipp@web.de>
Acked-by: Tilman Schmidt <tilman@imap.cc>
Cc: Karsten Keil <kkeil@suse.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The following patch to the common part of the Siemens Gigaset driver
prevents it from trying to send the +++ break sequence if the device has
been disconnected, and removes a couple of assignments which didn't have
any effect.
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Acked-by: Hansjoerg Lipp <hjlipp@web.de>
Cc: Karsten Keil <kkeil@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The following patch to the Siemens Gigaset base driver adds graceful
recovery for some frequently encountered error conditions, by retrying
failed control requests (eg. stalled control pipe), and by closing and
reopening the AT command channel when it appears to be stuck.
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Acked-by: Hansjoerg Lipp <hjlipp@web.de>
Cc: Karsten Keil <kkeil@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This fixes coverity bug #517.
Since IESIZE is greater than IESIZE_NI1 we might run past the end of
ielist_ni1. This fixes it by using the proper IESIZE_NI1 define.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Acked-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I am getting more or less reproducible crashes from the CAPI subsystem
using the fcdsl driver:
Unable to handle kernel NULL pointer dereference at virtual address 00000010
printing eip:
c39bbca4
*pde = 00000000
Oops: 0000 [#1]
Modules linked in: netconsole capi capifs 3c59x mii fcdsl kernelcapi uhci_hcd usbcore ide_cd cdrom
CPU: 0
EIP: 0060:[<c39bbca4>] Tainted: P VLI
EFLAGS: 00010202 (2.6.16.11 #3)
EIP is at handle_minor_send+0x17a/0x241 [capi]
eax: c24abbc0 ebx: c0b4c980 ecx: 00000010 edx: 00000010
esi: c1679140 edi: c2783016 ebp: 0000c28d esp: c0327e24
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c0326000 task=c02e1300)
Stack: <0>000005b4 c1679180 00000000 c28d0000 c1ce04e0 c2f69654 c221604e c1679140
c39bc19a 00000038 c20c0400 c075c560 c1f2f800 00000000 c01dc9b5 c1e96a40
c075c560 c2ed64c0 c1e96a40 c01dcd3b c2fb94e8 c075c560 c0327f00 c1e96a40
Call Trace:
[<c39bc19a>] capinc_tty_write+0xda/0xf3 [capi]
[<c01dc9b5>] ppp_sync_push+0x52/0xfe
[<c01dcd3b>] ppp_sync_send+0x1f5/0x204
[<c01d9bc1>] ppp_push+0x3e/0x9c
[<c01dacd4>] ppp_xmit_process+0x422/0x4cc
[<c01daf3f>] ppp_start_xmit+0x1c1/0x1f6
[<c0213ea5>] qdisc_restart+0xa7/0x135
[<c020b112>] dev_queue_xmit+0xba/0x19e
[<c0223f69>] ip_output+0x1eb/0x236
[<c0220907>] ip_forward+0x1c1/0x21a
[<c021fa6c>] ip_rcv+0x38e/0x3ea
[<c020b4c2>] netif_receive_skb+0x166/0x195
[<c020b55e>] process_backlog+0x6d/0xd2
[<c020a30f>] net_rx_action+0x6a/0xff
[<c0112909>] __do_softirq+0x35/0x7d
[<c0112973>] do_softirq+0x22/0x26
[<c0103a9d>] do_IRQ+0x1e/0x25
[<c010255a>] common_interrupt+0x1a/0x20
[<c01013c5>] default_idle+0x2b/0x53
[<c0101426>] cpu_idle+0x39/0x4e
[<c0328386>] start_kernel+0x20b/0x20d
Code: c0 e8 b3 b6 77 fc 85 c0 75 10 68 d8 c8 9b c3 e8 82 3d 75 fc 8b 43 60 5a eb 50 8d 56 50 c7 00 00 00 00 00 66 89 68 04 eb 02 89
ca <8b> 0a 85 c9 75 f8 89 02 89 da ff 46 54 8b 46 10 e8 30 79 fd ff
<0>Kernel panic - not syncing: Fatal exception in interrupt
That oops took me to the "ackqueue" implementation in capi.c. The crash
occured in capincci_add_ack() (auto-inlined by the compiler).
I read the code a bit and finally decided to replace the custom linked list
implementation (struct capiminor->ackqueue) by a struct list_head. That
did not solve the crash, but produced the following interresting oops:
Unable to handle kernel paging request at virtual address 00200200
printing eip:
c39bb1f5
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: netconsole capi capifs 3c59x mii fcdsl kernelcapi uhci_hcd usbcore ide_cd cdrom
CPU: 0
EIP: 0060:[<c39bb1f5>] Tainted: P VLI
EFLAGS: 00010246 (2.6.16.11 #3)
EIP is at capiminor_del_ack+0x18/0x49 [capi]
eax: 00200200 ebx: c18d41a0 ecx: c1385620 edx: 00100100
esi: 0000d147 edi: 00001103 ebp: 0000d147 esp: c1093f3c
ds: 007b es: 007b ss: 0068
Process events/0 (pid: 3, threadinfo=c1092000 task=c1089030)
Stack: <0>c2a17580 c18d41a0 c39bbd16 00000038 c18d41e0 00000000 d147c640 c29e0b68
c29e0b90 00000212 c29e0b68 c39932b2 c29e0bb0 c10736a0 c0119ef0 c399326c
c10736a8 c10736a0 c10736b0 c0119f93 c011a06e 00000001 00000000 00000000
Call Trace:
[<c39bbd16>] handle_minor_send+0x1af/0x241 [capi]
[<c39932b2>] recv_handler+0x46/0x5f [kernelcapi]
[<c0119ef0>] run_workqueue+0x5e/0x8d
[<c399326c>] recv_handler+0x0/0x5f [kernelcapi]
[<c0119f93>] worker_thread+0x0/0x10b
[<c011a06e>] worker_thread+0xdb/0x10b
[<c010c998>] default_wake_function+0x0/0xc
[<c011c399>] kthread+0x90/0xbc
[<c011c309>] kthread+0x0/0xbc
[<c0100a65>] kernel_thread_helper+0x5/0xb
Code: 7e 02 89 ee 89 f0 5a f7 d0 c1 f8 1f 5b 21 f0 5e 5f 5d c3 56 53 8b 48 50 89 d6 89 c3 8b 11 eb 2f 66 39 71 08 75 25 8b 41 04 8b 11 <89> 10 89 42 04 c7 01 00 01 10 00 89 c8 c7 41 04 00 02 20 00 e8
The interresting part of it is the "virtual address 00200200", which is
LIST_POISON2. I thought about some race condition, but as this is an UP
system, it leads to questions on how it can happen. If we look at EFLAGS:
00010202, we see that interrupts are enabled at the time of the crash
(eflags & 0x200).
Finally, I don't understand all the capi code, but I think that
handle_minor_send() is racing somehow against capi_recv_message(), which
call both capiminor_del_ack(). So if an IRQ occurs in the middle of
capiminor_del_ack() and another instance of it is invoked, it leads to
linked list corruption.
I came up with the following patch. With this, I could not reproduce the
crash anymore. Clearly, this is not the correct fix for the issue. As this
seems to be some locking issue, there might be more locking issues in that
code. For example, doesn't the whole struct capiminor have to be locked
somehow?
Cc: Carsten Paeth <calle@calle.de>
Cc: Kai Germaschewski <kai.germaschewski@gmx.de>
Cc: Karsten Keil <kkeil@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
With this patch Kprobes now registers for page fault notifications only when
their is an active probe registered. Once all the active probes are
unregistered their is no need to be notified of page faults and kprobes
unregisters itself from the page fault notifications. Hence we will have ZERO
side effects when no probes are active.
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Kprobes now registers for page fault notifications.
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavmurthy@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Overloading of page fault notification with the notify_die() has performance
issues(since the only interested components for page fault is kprobes and/or
kdb) and hence this patch introduces the new notifier call chain exclusively
for page fault notifications their by avoiding notifying unnecessary
components in the do_page_fault() code path.
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Overloading of page fault notification with the notify_die() has performance
issues(since the only interested components for page fault is kprobes and/or
kdb) and hence this patch introduces the new notifier call chain exclusively
for page fault notifications their by avoiding notifying unnecessary
components in the do_page_fault() code path.
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
