Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 7月, 2010 9 次提交
    • J
      rlimits: redo do_setrlimit to more generic do_prlimit · 5b41535a
      由 Jiri Slaby 提交于 
      It now allows also reading of limits. I.e. all read and writes will
later use this function.

It takes two parameters, new and old limits which can be both NULL.
If new is non-NULL, the value in it is set to rlimits.
If old is non-NULL, current rlimits are stored there.
If both are non-NULL, old are stored prior to setting the new ones,
atomically.
(Similar to sigaction.)
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      5b41535a
    • J
      rlimits: add rlimit64 structure · 6a1d5e2c
      由 Jiri Slaby 提交于 
      Add a platform independent structure for resource limits to use with
a new prlimit64 syscall. This structure is the same which uses glibc
for 64-bit limits.

Also add corresponding infinity which is a 64-bit full of bit-ones.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      6a1d5e2c
    • J
      rlimits: do security check under task_lock · 86f162f4
      由 Jiri Slaby 提交于 
      Do security_task_setrlimit under task_lock. Other tasks may change
limits under our hands while we are checking limits inside the
function. From now on, they can't.

Note that all the security work is done under a spinlock here now.
Security hooks count with that, they are called from interrupt context
(like security_task_kill) and with spinlocks already held (e.g.
capable->security_capable).
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NJames Morris <jmorris@namei.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      86f162f4
    • J
      rlimits: allow setrlimit to non-current tasks · 1c1e618d
      由 Jiri Slaby 提交于 
      Add locking to allow setrlimit accept task parameter other than
current.

Namely, lock tasklist_lock for read and check whether the task
structure has sighand non-null. Do all the signal processing under
that lock still held.

There are some points:
1) security_task_setrlimit is now called with that lock held. This is
   not new, many security_* functions are called with this lock held
   already so it doesn't harm (all this security_* stuff does almost
   the same).
2) task->sighand->siglock (in update_rlimit_cpu) is nested in
   tasklist_lock. This dependence is already existing.
3) tsk->alloc_lock is nested in tasklist_lock. This is OK too, already
   existing dependence.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
      1c1e618d
    • J
      rlimits: split sys_setrlimit · 7855c35d
      由 Jiri Slaby 提交于 
      Create do_setrlimit from sys_setrlimit and declare do_setrlimit
in the resource header. This is the first phase to have generic
do_prlimit which allows to be called from read, write and compat
rlimits code.

The new do_setrlimit also accepts a task pointer to change the limits
of. Currently, it cannot be other than current, but this will change
with locking later.

Also pass tsk->group_leader to security_task_setrlimit to check
whether current is allowed to change rlimits of the process and not
its arbitrary thread because it makes more sense given that rlimit are
per process and not per-thread.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      7855c35d
    • O
      rlimits: selinux, do rlimits changes under task_lock · eb2d55a3
      由 Oleg Nesterov 提交于 
      When doing an exec, selinux updates rlimits in its code of current
process depending on current max. Make sure max or cur doesn't change
in the meantime by grabbing task_lock which do_prlimit needs for
changing limits too.

While at it, use rlimit helper for accessing CPU rlimit a line below.
To have a volatile access too.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Oleg Nesterov <oleg@redhat.com>
      eb2d55a3
    • O
      rlimits: make sure ->rlim_max never grows in sys_setrlimit · 2fb9d268
      由 Oleg Nesterov 提交于 
      Mostly preparation for Jiri's changes, but probably makes sense anyway.

sys_setrlimit() checks new_rlim.rlim_max <= old_rlim->rlim_max, but when
it takes task_lock() old_rlim->rlim_max can be already lowered. Move this
check under task_lock().

Currently this is not important, we can only race with our sub-thread,
this means the application is stupid. But when we change the code to allow
the update of !current task's limits, it becomes important to make sure
->rlim_max can be lowered "reliably" even if we race with the application
doing sys_setrlimit().
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      2fb9d268
    • J
      rlimits: add task_struct to update_rlimit_cpu · 5ab46b34
      由 Jiri Slaby 提交于 
      Add task_struct as a parameter to update_rlimit_cpu to be able to set
rlimit_cpu of different task than current.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Acked-by: NJames Morris <jmorris@namei.org>
      5ab46b34
    • J
      rlimits: security, add task_struct to setrlimit · 8fd00b4d
      由 Jiri Slaby 提交于 
      Add task_struct to task_setrlimit of security_operations to be able to set
rlimit of task other than current.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Acked-by: NEric Paris <eparis@redhat.com>
Acked-by: NJames Morris <jmorris@namei.org>
      8fd00b4d
  3. 15 7月, 2010 4 次提交
  5. 14 7月, 2010 3 次提交
  7. 13 7月, 2010 8 次提交
  9. 12 7月, 2010 10 次提交
  11. 10 7月, 2010 3 次提交
    • R
      ARM: lockdep: fix unannotated irqs-on · ac78884e
      由 Russell King 提交于 
      CPU: Testing write buffer coherency: ok
------------[ cut here ]------------
WARNING: at kernel/lockdep.c:3145 check_flags+0xcc/0x1dc()
Modules linked in:
[<c0035120>] (unwind_backtrace+0x0/0xf8) from [<c0355374>] (dump_stack+0x20/0x24)
[<c0355374>] (dump_stack+0x20/0x24) from [<c0060c04>] (warn_slowpath_common+0x58/0x70)
[<c0060c04>] (warn_slowpath_common+0x58/0x70) from [<c0060c3c>] (warn_slowpath_null+0x20/0x24)
[<c0060c3c>] (warn_slowpath_null+0x20/0x24) from [<c008f224>] (check_flags+0xcc/0x1dc)
[<c008f224>] (check_flags+0xcc/0x1dc) from [<c00945dc>] (lock_acquire+0x50/0x140)
[<c00945dc>] (lock_acquire+0x50/0x140) from [<c0358434>] (_raw_spin_lock+0x50/0x88)
[<c0358434>] (_raw_spin_lock+0x50/0x88) from [<c00fd114>] (set_task_comm+0x2c/0x60)
[<c00fd114>] (set_task_comm+0x2c/0x60) from [<c007e184>] (kthreadd+0x30/0x108)
[<c007e184>] (kthreadd+0x30/0x108) from [<c0030104>] (kernel_thread_exit+0x0/0x8)
---[ end trace 1b75b31a2719ed1c ]---
possible reason: unannotated irqs-on.
irq event stamp: 3
hardirqs last  enabled at (2): [<c0059bb0>] finish_task_switch+0x48/0xb0
hardirqs last disabled at (3): [<c002f0b0>] ret_slow_syscall+0xc/0x1c
softirqs last  enabled at (0): [<c005f3e0>] copy_process+0x394/0xe5c
softirqs last disabled at (0): [<(null)>] (null)

Fix this by ensuring that the lockdep interrupt state is manipulated in
the appropriate places.  We essentially treat userspace as an entirely
separate environment which isn't relevant to lockdep (lockdep doesn't
monitor userspace.)  We don't tell lockdep that IRQs will be enabled
in that environment.

Instead, when creating kernel threads (which is a rare event compared
to entering/leaving userspace) we have to update the lockdep state.  Do
this by starting threads with IRQs disabled, and in the kthread helper,
tell lockdep that IRQs are enabled, and enable them.

This provides lockdep with a consistent view of the current IRQ state
in kernel space.

This also revert portions of 0d928b0b
which didn't fix the problem.
Tested-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ac78884e
    • G
      i2c/mips: Fix error return codes from Sibyte i2c bus driver · 102b59c6
      由 Guenter Roeck 提交于 
      Sibyte i2c bus driver returns non-descriptive error values.
Update to return error values as defined in Documentation/i2c/fault-codes.
Signed-off-by: NGuenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
      102b59c6
    • J
      i2c: Fix probability check · 827900c5
      由 Jean Delvare 提交于 
      The new unified probing function differs from the original code, and
the preliminary test whether probing is possible must be updated
accordingly.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
      827900c5
  13. 09 7月, 2010 3 次提交