Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 21 9月, 2009 2 次提交
    • H
      thinkpad-acpi: hotkey event driver update · 0d922e3b
      由 Henrique de Moraes Holschuh 提交于 
      Update the HKEY event driver to:

1. Handle better the second-gen firmware, which has no HKEY mask
   support but does report FN+F3, FN+F4 and FN+F12 without the need
   for NVRAM polling.

   a) always make the mask-related attributes available in sysfs;
   b) use DMI quirks to detect the second-gen firmware;
   c) properly report that FN+F3, FN+F4 and FN+F12 are enabled,
      and available even on mask-less second-gen firmware;

2. Decouple the issuing of hotkey events towards userspace from
   their reception from the firmware.  ALSA mixer and brightness
   event reporting support will need this feature.

3. Clean up the mess in the hotkey driver a great deal.  It is
   still very convoluted, and wants a full refactoring into a
   proper event API interface, but that is not going to happen
   today.

4. Fully reset firmware interface on resume (restore hotkey
   mask and status).

5. Stop losing polled events for no good reason when changing the
   mask and poll frequencies.  We will still lose them when the
   hotkey_source_mask is changed, as well as any that happened
   between driver suspend and driver resume.

The hotkey subdriver now has the notion of user-space-visible hotkey
event mask, as well as of the set of "hotkey" events the driver needs
(because brightness/volume change reports are not just keypress
reports in most ThinkPad models).

With this rewrite, the ABI level is bumped to 0x020500 should
userspace need to know it is dealing with the updated hotkey
subdriver.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>
      0d922e3b
    • H
      thinkpad-acpi: drop HKEY event 0x5010 · 176dd985
      由 Henrique de Moraes Holschuh 提交于 
      HKEY event 0x5010 is useless to us: old ThinkPads don't issue it.  Newer
ThinkPads won't issue it anymore.  And all ThinkPads issue 0x1010 and
0x1011 events.

Just silently drop it instead of sending it to userspace.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>
      176dd985
  3. 19 9月, 2009 2 次提交
  5. 20 8月, 2009 1 次提交
  7. 19 8月, 2009 1 次提交
    • K
      mm: revert "oom: move oom_adj value" · 0753ba01
      由 KOSAKI Motohiro 提交于 
      The commit 2ff05b2b (oom: move oom_adj value) moveed the oom_adj value to
the mm_struct.  It was a very good first step for sanitize OOM.

However Paul Menage reported the commit makes regression to his job
scheduler.  Current OOM logic can kill OOM_DISABLED process.

Why? His program has the code of similar to the following.

	...
	set_oom_adj(OOM_DISABLE); /* The job scheduler never killed by oom */
	...
	if (vfork() == 0) {
		set_oom_adj(0); /* Invoked child can be killed */
		execve("foo-bar-cmd");
	}
	....

vfork() parent and child are shared the same mm_struct.  then above
set_oom_adj(0) doesn't only change oom_adj for vfork() child, it's also
change oom_adj for vfork() parent.  Then, vfork() parent (job scheduler)
lost OOM immune and it was killed.

Actually, fork-setting-exec idiom is very frequently used in userland program.
We must not break this assumption.

Then, this patch revert commit 2ff05b2b and related commit.

Reverted commit list
---------------------
- commit 2ff05b2b (oom: move oom_adj value from task_struct to mm_struct)
- commit 4d8b9135 (oom: avoid unnecessary mm locking and scanning for OOM_DISABLE)
- commit 81236810 (oom: only oom kill exiting tasks with attached memory)
- commit 933b787b (mm: copy over oom_adj value at fork time)
Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Paul Menage <menage@google.com>
Cc: David Rientjes <rientjes@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0753ba01
  9. 18 8月, 2009 1 次提交
  11. 14 8月, 2009 3 次提交
  13. 12 8月, 2009 1 次提交
  15. 10 8月, 2009 1 次提交
  17. 07 8月, 2009 1 次提交
  19. 02 8月, 2009 1 次提交
    • H
      thinkpad-acpi: remove dock and bay subdrivers · 1f6fc2de
      由 Henrique de Moraes Holschuh 提交于 
      The standard ACPI dock driver can handle the hotplug bays and docks of
the ThinkPads just fine (including batteries) as of 2.6.27, and the
code in thinkpad-acpi for the dock and bay subdrivers is currently
broken anyway...

Userspace needs some love to support the two-stage ejection nicely,
but it is simple enough to do through udev rules (you don't even need
HAL) so this wouldn't justify fixing the dock and bay subdrivers,
either.

That leaves warm-swap bays (_EJ3) support for thinkpad-acpi, as well
as support for the weird dock of the model 570, but since such support
has never left the "experimental" stage, it is also not a strong
enough reason to find a way to fix this code.

Users of ThinkPads with warm-swap bays are urged to request that _EJ3
support be added to the regular ACPI dock driver, if such feature is
indeed useful for them.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>
      1f6fc2de
  21. 01 8月, 2009 1 次提交
  23. 31 7月, 2009 1 次提交
  25. 30 7月, 2009 6 次提交
  27. 29 7月, 2009 1 次提交
  29. 25 7月, 2009 2 次提交
  31. 23 7月, 2009 1 次提交
    • T
      ALSA: pcm - Add logging of hwptr updates and interrupt updates · cedb8118
      由 Takashi Iwai 提交于 
      Added the logging functionality to xrun_debug to record the hwptr
updates via snd_pcm_update_hw_ptr() and snd_pcm_update_hwptr_interrupt(),
corresponding to 16 and 8, respectively.

For example,
	# echo 9 > /proc/asound/card0/pcm0p/xrun_debug
will record the position and other parameters at each period interrupt
together with the normal XRUN debugging.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      cedb8118
  33. 22 7月, 2009 1 次提交
  35. 18 7月, 2009 1 次提交
  37. 16 7月, 2009 1 次提交
    • E
      netfilter: nf_conntrack: nf_conntrack_alloc() fixes · 941297f4
      由 Eric Dumazet 提交于 
      When a slab cache uses SLAB_DESTROY_BY_RCU, we must be careful when allocating
objects, since slab allocator could give a freed object still used by lockless
readers.

In particular, nf_conntrack RCU lookups rely on ct->tuplehash[xxx].hnnode.next
being always valid (ie containing a valid 'nulls' value, or a valid pointer to next
object in hash chain.)

kmem_cache_zalloc() setups object with NULL values, but a NULL value is not valid
for ct->tuplehash[xxx].hnnode.next.

Fix is to call kmem_cache_alloc() and do the zeroing ourself.

As spotted by Patrick, we also need to make sure lookup keys are committed to
memory before setting refcount to 1, or a lockless reader could get a reference
on the old version of the object. Its key re-check could then pass the barrier.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NPatrick McHardy <kaber@trash.net>
      941297f4
  39. 13 7月, 2009 1 次提交
  41. 11 7月, 2009 2 次提交
  43. 10 7月, 2009 1 次提交
  45. 09 7月, 2009 1 次提交
  47. 07 7月, 2009 1 次提交
  49. 06 7月, 2009 3 次提交
  51. 01 7月, 2009 2 次提交