Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 03 4月, 2009 10 次提交
  3. 02 4月, 2009 4 次提交
  5. 01 4月, 2009 6 次提交
  7. 31 3月, 2009 3 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      由 Alexey Dobriyan 提交于 
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
as correctly noted at bug #12454. Someone can lookup entry with NULL
->owner, thus not pinning enything, and release it later resulting
in module refcount underflow.

We can keep ->owner and supply it at registration time like ->proc_fops
and ->data.

But this leaves ->owner as easy-manipulative field (just one C assignment)
and somebody will forget to unpin previous/pin current module when
switching ->owner. ->proc_fops is declared as "const" which should give
some thoughts.

->read_proc/->write_proc were just fixed to not require ->owner for
protection.

rmmod'ed directories will be empty and return "." and ".." -- no harm.
And directories with tricky enough readdir and lookup shouldn't be modular.
We definitely don't want such modular code.

Removing ->owner will also make PDE smaller.

So, let's nuke it.

Kudos to Jeff Layton for reminding about this, let's say, oversight.

http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
    • R
      PM: Rework handling of interrupts during suspend-resume · 2ed8d2b3
      由 Rafael J. Wysocki 提交于 
      Use the functions introduced in by the previous patch,
suspend_device_irqs(), resume_device_irqs() and check_wakeup_irqs(),
to rework the handling of interrupts during suspend (hibernation) and
resume.  Namely, interrupts will only be disabled on the CPU right
before suspending sysdevs, while device drivers will be prevented
from receiving interrupts, with the help of the new helper function,
before their "late" suspend callbacks run (and analogously during
resume).

In addition, since the device interrups are now disabled before the
CPU has turned all interrupts off and the CPU will ACK the interrupts
setting the IRQ_PENDING bit for them, check in sysdev_suspend() if
any wake-up interrupts are pending and abort suspend if that's the
case.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NIngo Molnar <mingo@elte.hu>
      2ed8d2b3
    • S
      x86: fix mismerge in arch/x86/include/asm/timer.h · 25c1a411
      由 Stephen Rothwell 提交于 
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      25c1a411
  9. 30 3月, 2009 4 次提交
  11. 29 3月, 2009 3 次提交
  13. 28 3月, 2009 1 次提交
    • C
      generic compat_sys_ustat · 2b1c6bd7
      由 Christoph Hellwig 提交于 
      Due to a different size of ino_t ustat needs a compat handler, but
currently only x86 and mips provide one.  Add a generic compat_sys_ustat
and switch all architectures over to it.  Instead of doing various
user copy hacks compat_sys_ustat just reimplements sys_ustat as
it's trivial.  This was suggested by Arnd Bergmann.

Found by Eric Sandeen when running xfstests/017 on ppc64, which causes
stack smashing warnings on RHEL/Fedora due to the too large amount of
data writen by the syscall.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      2b1c6bd7
  15. 27 3月, 2009 2 次提交
  17. 26 3月, 2009 3 次提交
  19. 25 3月, 2009 3 次提交
    • W
      x86: early_ioremap_init(), use __fix_to_virt(), because we are sure it's safe · 9f4f25c8
      由 Wang Chen 提交于 
      Tetsuo Handa reported this link bug:

 |  arch/x86/mm/built-in.o(.init.text+0x1831): In function `early_ioremap_init':
 |  : undefined reference to `__this_fixmap_does_not_exist'
 |  make: *** [.tmp_vmlinux1] Error 1

Commit:8827247f used a variable (which
would be optimized to constant) as fix_to_virt()'s parameter.
It's depended on gcc's optimization and fails on old gcc. (Tetsuo used gcc 3.3)

We can use __fix_to_vir() instead, because we know it's safe and
don't need link time error reporting.
Reported-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
Cc: sfr@canb.auug.org.au
LKML-Reference: <49C9FFEA.7060908@cn.fujitsu.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9f4f25c8
    • Y
      x86: use default_cpu_mask_to_apicid for 64bit · f56e5034
      由 Yinghai Lu 提交于 
      Impact: cleanup

Use online_mask directly on 64bit too.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
LKML-Reference: <49C94DAE.9070300@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f56e5034
    • Y
      x86: fix set_extra_move_desc calling · fa74c907
      由 Yinghai Lu 提交于 
      Impact: fix bug with irq-descriptor moving when logical flat

Rusty observed:

> The effect of setting desc->affinity (ie. from userspace via sysfs) has varied
> over time.  In 2.6.27, the 32-bit code anded the value with cpu_online_map,
> and both 32 and 64-bit did that anding whenever a cpu was unplugged.
>
> 2.6.29 consolidated this into one routine (and fixed hotplug) but introduced
> another variation: anding the affinity with cfg->domain.  Is this right, or
> should we just set it to what the user said?  Or as now, indicate that we're
> restricting it.

Eric pointed out that desc->affinity should be what the user requested,
if it is at all possible to honor the user space request.

This bug got introduced by commit 22f65d31 "x86: Update io_apic.c to use
new cpumask API".

Fix it by moving the masking to before the descriptor moving ...
Reported-by: NRusty Russell <rusty@rustcorp.com.au>
Reported-by: NEric W. Biederman <ebiederm@xmission.com>
LKML-Reference: <49C94134.4000408@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fa74c907
  21. 24 3月, 2009 1 次提交