Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 3月, 2010 1 次提交
  3. 30 12月, 2009 1 次提交
    • I
      ACPI: fix ACPI=n allmodconfig build · 27d0567a
      由 Ingo Molnar 提交于 
      Today's -tip failed to build because commit
9e368fa0 ("ipmi: add PNP discovery (ACPI
namespace via PNPACPI)") from today's upstream kernel causes the following
build failure on x86, for CONFIG_ACPI=n && CONFIG_IPMI_SI=y:

 drivers/char/ipmi/ipmi_si_intf.c:3208: error: 'ipmi_pnp_driver' undeclared (first use in this function)
 drivers/char/ipmi/ipmi_si_intf.c:3208: error: (Each undeclared identifier is reported only once
 drivers/char/ipmi/ipmi_si_intf.c:3208: error: for each function it appears in.)
 drivers/char/ipmi/ipmi_si_intf.c:3334: error: 'ipmi_pnp_driver' undeclared (first use in this function)

The reason is that the ipmi_pnp_driver depends on ACPI facilities and is only
made available under ACPI - while the registration and unregistration is made
dependent on CONFIG_PNP:

 #ifdef CONFIG_PNP
 	pnp_register_driver(&ipmi_pnp_driver);
 #endif

The solution is to only register this driver under ACPI. (Also, the CONFIG_PNP
dependency is not needed because pnp_register_driver() is stubbed out in the
!CONFIG_PNP case.)
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NMyron Stowe <myron.stowe@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      27d0567a
  5. 16 12月, 2009 4 次提交
  7. 19 11月, 2009 1 次提交
  9. 12 11月, 2009 1 次提交
    • E
      sysctl drivers: Remove dead binary sysctl support · 894d2491
      由 Eric W. Biederman 提交于 
      Now that sys_sysctl is a wrapper around /proc/sys all of
the binary sysctl support elsewhere in the tree is
dead code.

Cc: Jens Axboe <axboe@kernel.dk>
Cc: Corey Minyard <minyard@acm.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Neil Brown <neilb@suse.de>
Cc: "James E.J. Bottomley" <James.Bottomley@suse.de>
Acked-by: Clemens Ladisch <clemens@ladisch.de> for drivers/char/hpet.c
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      894d2491
  11. 05 10月, 2009 1 次提交
  13. 21 9月, 2009 1 次提交
  15. 16 6月, 2009 1 次提交
  17. 22 5月, 2009 1 次提交
    • C
      ipmi: fix ipmi_si modprobe hang · 9a2845c4
      由 Corey Minyard 提交于 
      Instead of queuing IPMB messages before channel initialization, just
throw them away.  Nobody will be listening for them at this point,
anyway, and they will clog up the queue and nothing will be delivered
if we queue them.

Also set the current channel to the number of channels, as this value
is used to tell if the channel information has been initialized.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Ferenc Wagner <wferi@niif.hu>
Cc: Dan Frazier <dannf@hp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9a2845c4
  19. 22 4月, 2009 4 次提交
  21. 31 3月, 2009 1 次提交
    • 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
  23. 13 11月, 2008 1 次提交
  25. 02 11月, 2008 1 次提交
    • A
      saner FASYNC handling on file close · 233e70f4
      由 Al Viro 提交于 
      As it is, all instances of ->release() for files that have ->fasync()
need to remember to evict file from fasync lists; forgetting that
creates a hole and we actually have a bunch that *does* forget.

So let's keep our lives simple - let __fput() check FASYNC in
file->f_flags and call ->fasync() there if it's been set.  And lose that
crap in ->release() instances - leaving it there is still valid, but we
don't have to bother anymore.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  27. 31 10月, 2008 1 次提交
  29. 17 10月, 2008 1 次提交
  31. 23 9月, 2008 1 次提交
  33. 21 8月, 2008 1 次提交
  35. 30 7月, 2008 1 次提交
  37. 22 7月, 2008 1 次提交
  39. 12 7月, 2008 1 次提交
  41. 03 7月, 2008 1 次提交
  43. 21 6月, 2008 2 次提交
  45. 15 5月, 2008 1 次提交
  47. 29 4月, 2008 10 次提交