headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

i915: fix intel graphics suspend breakage due to resume/lid event confusion

Gitweb:     http://git.kernel.org/linus/c9354c85c1c7bac788ce57d3c17f2016c1c45b1d
Commit:     c9354c85c1c7bac788ce57d3c17f2016c1c45b1d
Parent:     b6727b12dd2ffb4a890eb5b13a298230c29ba45d
Author:     Linus Torvalds <torvalds <at> linux-foundation.org>
AuthorDate: Mon Nov 2 09:29:55 2009 -0800
Committer:  Linus Torvalds <torvalds <at> linux-foundation.org>
CommitDate: Mon Nov 2 09:29:55 2009 -0800

    i915: fix intel graphics suspend breakage due to resume/lid event confusion

    In commit c1c7af60892070e4b82ad63bbfb95ae745056de0 ("drm/i915: force
    mode set at lid open time") the intel graphics driver was taught to
    restore the LVDS mode on lid open.

    That caused problems with interaction with the suspend/resume code,
    which commonly runs at the same time (suspend is often caused by the lid
    close event, while lid open is commonly a resume event), which was
    worked around with in commit 06891e27a9b5dba5268bb80e41a283f51335afe7
    ("drm/i915: fix suspend/resume breakage in lid notifier").

    However, in the meantime the lid event code had also grown a user event
    notifier (commit 06324194eee97a51b5f172270df49ec39192d6cc: "drm/i915:
    generate a KMS uevent at lid open/close time"), and now _that_ causes
    problems with suspend/resume and some versions of Xorg reacting to those
    uevents by setting the mode.

    So this effectively reverts that commit 06324194ee, and makes the lid
    open protection logic against suspend/resume more explicit.  This fixes
    at least one laptop. See
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

x86: Remove STACKPROTECTOR_ALL

Gitweb:     http://git.kernel.org/linus/14a3f40aafacde1dfd6912327ae14df4baf10304
Commit:     14a3f40aafacde1dfd6912327ae14df4baf10304
Parent:     02dd0a0613e0d84c7dd8315e3fe6204d005b7c79
Author:     Arjan van de Ven <arjan <at> infradead.org>
AuthorDate: Fri Oct 23 07:31:01 2009 -0700
Committer:  Ingo Molnar <mingo <at> elte.hu>
CommitDate: Fri Oct 23 16:35:23 2009 +0200

    x86: Remove STACKPROTECTOR_ALL

    STACKPROTECTOR_ALL has a really high overhead (runtime and stack
    footprint) and is not really worth it protection wise (the
    normal STACKPROTECTOR is in effect for all functions with
    buffers already), so lets just remove the option entirely.

    Reported-by: Dave Jones <davej <at> redhat.com>
    Reported-by: Chuck Ebbert <cebbert <at> redhat.com>
    Signed-off-by: Arjan van de Ven <arjan <at> linux.intel.com>
    Cc: Eric Sandeen <sandeen <at> redhat.com>
    LKML-Reference: <20091023073101.3dce4ebb <at> infradead.org>
    Signed-off-by: Ingo Molnar <mingo <at> elte.hu>
---
 arch/x86/Kconfig  |    4 ----
 arch/x86/Makefile |    1 -
 2 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 07e0114..72ace95 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
(Continue reading)

Permalink | Reply | 3 comments |
headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

tracing: Remove cpu arg from the rb_time_stamp() function

Gitweb:     http://git.kernel.org/linus/6d3f1e12f46a2f9a1bb7e7aa433df8dd31ce5647
Commit:     6d3f1e12f46a2f9a1bb7e7aa433df8dd31ce5647
Parent:     67b394f7f26d84edb7294cc6528ab7ca6daa2ad1
Author:     Jiri Olsa <jolsa <at> redhat.com>
AuthorDate: Fri Oct 23 19:36:19 2009 -0400
Committer:  Ingo Molnar <mingo <at> elte.hu>
CommitDate: Sat Oct 24 11:07:51 2009 +0200

    tracing: Remove cpu arg from the rb_time_stamp() function

    The cpu argument is not used inside the rb_time_stamp() function.
    Plus fix a typo.

    Signed-off-by: Jiri Olsa <jolsa <at> redhat.com>
    Signed-off-by: Steven Rostedt <rostedt <at> goodmis.org>
    Cc: Frederic Weisbecker <fweisbec <at> gmail.com>
    LKML-Reference: <20091023233647.118547500 <at> goodmis.org>
    Signed-off-by: Ingo Molnar <mingo <at> elte.hu>
---
 include/linux/trace_seq.h  |    2 +-
 kernel/trace/ring_buffer.c |   10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/trace_seq.h b/include/linux/trace_seq.h
index c134dd1..09077f6 100644
--- a/include/linux/trace_seq.h
+++ b/include/linux/trace_seq.h
 <at>  <at>  -7,7 +7,7  <at>  <at> 

 /*
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

futex: Fix spurious wakeup for requeue_pi really

Gitweb:     http://git.kernel.org/linus/11df6dddcbc38affb7473aad3d962baf8414a947
Commit:     11df6dddcbc38affb7473aad3d962baf8414a947
Parent:     89061d3d58e1f0742139605dc6a7950aa1ecc019
Author:     Thomas Gleixner <tglx <at> linutronix.de>
AuthorDate: Wed Oct 28 20:26:48 2009 +0100
Committer:  Thomas Gleixner <tglx <at> linutronix.de>
CommitDate: Wed Oct 28 20:34:34 2009 +0100

    futex: Fix spurious wakeup for requeue_pi really

    The requeue_pi path doesn't use unqueue_me() (and the racy lock_ptr ==
    NULL test) nor does it use the wake_list of futex_wake() which where
    the reason for commit 41890f2 (futex: Handle spurious wake up)

    See debugging discussing on LKML Message-ID: <4AD4080C.20703 <at> us.ibm.com>

    The changes in this fix to the wait_requeue_pi path were considered to
    be a likely unecessary, but harmless safety net. But it turns out that
    due to the fact that for unknown $ <at> #!*( reasons EWOULDBLOCK is defined
    as EAGAIN we built an endless loop in the code path which returns
    correctly EWOULDBLOCK.

    Spurious wakeups in wait_requeue_pi code path are unlikely so we do
    the easy solution and return EWOULDBLOCK^WEAGAIN to user space and let
    it deal with the spurious wakeup.

    Cc: Darren Hart <dvhltc <at> us.ibm.com>
    Cc: Peter Zijlstra <peterz <at> infradead.org>
    Cc: Eric Dumazet <eric.dumazet <at> gmail.com>
    Cc: John Stultz <johnstul <at> linux.vnet.ibm.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

ASoC: Serialize access to dapm_power_widgets()

Gitweb:     http://git.kernel.org/linus/8e8b2d676f3f7c1246b108793fb5690e6c6fcd26
Commit:     8e8b2d676f3f7c1246b108793fb5690e6c6fcd26
Parent:     6f775ba0154cdf10108071acc71f26c4efdb8d57
Author:     Eero Nurkkala <ext-eero.nurkkala <at> nokia.com>
AuthorDate: Mon Oct 12 08:41:59 2009 +0300
Committer:  Mark Brown <broonie <at> opensource.wolfsonmicro.com>
CommitDate: Tue Oct 13 13:33:02 2009 +0100

    ASoC: Serialize access to dapm_power_widgets()

    Access to damp_power_widgets() is assumed to be single-threaded.
    Concurrent accesses to dapm_power_widgets() may result in
    unpredictable behavior.

    Calls from:
    close_delayed_work()
    soc_codec_close()
    soc_pcm_prepare()
    soc_suspend()
    soc_resume_deferred()
    to snd_soc_dapm_stream_event() do not have the codec->mutex
    taken to cover the call to dapm_power_widgets(). Thus, take
    the mutex in these paths also to assure single-threaded use
    of dapm_power_widgets().

    Signed-off-by: Eero Nurkkala <ext-eero.nurkkala <at> nokia.com>
    Signed-off-by: Mark Brown <broonie <at> opensource.wolfsonmicro.com>
---
 sound/soc/soc-dapm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

x86: Side-step lguest problem by only building cmpxchg8b_emu for pre-Pentium

Gitweb:     http://git.kernel.org/linus/ae1b22f6e46c03cede7cea234d0bf2253b4261cf
Commit:     ae1b22f6e46c03cede7cea234d0bf2253b4261cf
Parent:     14a3f40aafacde1dfd6912327ae14df4baf10304
Author:     Rusty Russell <rusty <at> rustcorp.com.au>
AuthorDate: Mon Oct 26 14:26:04 2009 +1030
Committer:  Ingo Molnar <mingo <at> elte.hu>
CommitDate: Mon Oct 26 12:33:02 2009 +0100

    x86: Side-step lguest problem by only building cmpxchg8b_emu for pre-Pentium

    Commit 79e1dd05d1a22 "x86: Provide an alternative() based
    cmpxchg64()" broke lguest, even on systems which have cmpxchg8b
    support.  The emulation code gets used until alternatives get
    run, but it contains native instructions, not their paravirt
    alternatives.

    The simplest fix is to turn this code off except for 386 and 486
    builds.

    Reported-by: Johannes Stezenbach <js <at> sig21.net>
    Signed-off-by: Rusty Russell <rusty <at> rustcorp.com.au>
    Acked-by: H. Peter Anvin <hpa <at> zytor.com>
    Cc: lguest <at> ozlabs.org
    Cc: Arjan van de Ven <arjan <at> infradead.org>
    Cc: Jeremy Fitzhardinge <jeremy <at> goop.org>
    Cc: Linus Torvalds <torvalds <at> linux-foundation.org>
    LKML-Reference: <200910261426.05769.rusty <at> rustcorp.com.au>
    Signed-off-by: Ingo Molnar <mingo <at> elte.hu>
---
 arch/x86/Kconfig.cpu |    2 +-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

ALSA: sound: Move dereference after NULL test and drop unnecessary NULL tests

Gitweb:     http://git.kernel.org/linus/4b3be6afa4ab8b3fdce39df68bad71f8b85164de
Commit:     4b3be6afa4ab8b3fdce39df68bad71f8b85164de
Parent:     b71207e9dc044b30d8b5d7f1c2290ba14563f05c
Author:     Julia Lawall <julia <at> diku.dk>
AuthorDate: Sat Oct 17 08:33:22 2009 +0200
Committer:  Takashi Iwai <tiwai <at> suse.de>
CommitDate: Fri Oct 30 12:01:27 2009 +0100

    ALSA: sound: Move dereference after NULL test and drop unnecessary NULL tests

    In pcm.c, if the NULL test on pcm is needed, then the dereference should be
    after the NULL test.

    In dummy.c and ali5451.c, the context of the calls to
    snd_card_dummy_new_mixer and snd_ali_free_voice show that dummy and pvoice,
    respectively cannot be NULL.

    A simplified version of the semantic match that detects this problem is as
    follows (http://coccinelle.lip6.fr/):

    // <smpl>
     <at> match exists <at> 
    expression x, E;
    identifier fld;
     <at>  <at> 

    * x->fld
      ... when != \(x = E\|&x\)
    * x == NULL
    // </smpl>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

perf tools: Fix compatibility with libelf 0.8 and autodetect

Gitweb:     http://git.kernel.org/linus/84087126d50400789b44459cfc45721778e6ebb0
Commit:     84087126d50400789b44459cfc45721778e6ebb0
Parent:     54f4407608c59712a8f5ec1e10dfac40bef5a2e7
Author:     Marti Raudsepp <marti <at> juffo.org>
AuthorDate: Sat Oct 24 19:10:36 2009 +0300
Committer:  Ingo Molnar <mingo <at> elte.hu>
CommitDate: Sun Oct 25 17:09:14 2009 +0100

    perf tools: Fix compatibility with libelf 0.8 and autodetect

    The Makefile now automatically defines LIBELF_NO_MMAP when
    libelf 0.8.x is detected. libelf 0.8 is still maintained and
    some distributions such as Arch Linux use it instead of
    elfutils.

    Signed-off-by: Marti Raudsepp <marti <at> juffo.org>
    Cc: Lucas De Marchi <lucas.de.marchi <at> gmail.com>
    Cc: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
    Cc: Paul Mackerras <paulus <at> samba.org>
    Cc: Frederic Weisbecker <fweisbec <at> gmail.com>
    Cc: Arnaldo Carvalho de Melo <acme <at> redhat.com>
    Cc: Arjan van de Ven <arjan <at> linux.intel.com>
    Cc: Mike Galbraith <efault <at> gmx.de>
    LKML-Reference: <1256400636.3007.16.camel <at> newn>
    Signed-off-by: Ingo Molnar <mingo <at> elte.hu>
---
 tools/perf/Makefile      |    6 +++++-
 tools/perf/util/symbol.c |    6 +++---
 tools/perf/util/symbol.h |   10 ++++++++++
 3 files changed, 18 insertions(+), 4 deletions(-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

x86: crash_dump: Fix non-pae kdump kernel memory accesses

Gitweb:     http://git.kernel.org/linus/72ed7de74e8f0fad0d8e567ae1f987b740accb3f
Commit:     72ed7de74e8f0fad0d8e567ae1f987b740accb3f
Parent:     ae1b22f6e46c03cede7cea234d0bf2253b4261cf
Author:     Jiri Slaby <jirislaby <at> gmail.com>
AuthorDate: Mon Oct 26 11:11:43 2009 +0100
Committer:  Ingo Molnar <mingo <at> elte.hu>
CommitDate: Mon Oct 26 12:38:59 2009 +0100

    x86: crash_dump: Fix non-pae kdump kernel memory accesses

    Non-PAE 32-bit dump kernels may wrap an address around 4G and
    poke unwanted space. ptes there are 32-bit long, and since
    pfn << PAGE_SIZE may exceed this limit, high pfn bits are
    cropped and wrong address mapped by kmap_atomic_pfn in
    copy_oldmem_page.

    Don't allow this behavior in non-PAE kdump kernels by checking
    pfns passed into copy_oldmem_page. In the case of failure,
    userspace process gets EFAULT.

    [v2]
    - fix comments
    - move ifdefs inside the function

    Signed-off-by: Jiri Slaby <jirislaby <at> gmail.com>
    Cc: Vivek Goyal <vgoyal <at> redhat.com>
    Cc: Eric W. Biederman <ebiederm <at> xmission.com>
    Cc: Simon Horman <horms <at> verge.net.au>
    Cc: Paul Mundt <lethal <at> linux-sh.org>
    LKML-Reference: <1256551903-30567-1-git-send-email-jirislaby <at> gmail.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linux Kernel Mailing List | 2 Nov 2009 19:59

tracing: Fix trace_seq_printf() return value

Gitweb:     http://git.kernel.org/linus/3e69533b51930a7169235db2caf703884e6e3bbb
Commit:     3e69533b51930a7169235db2caf703884e6e3bbb
Parent:     cf8517cf905b5cd31d5790250b9ac39f7cb8aa53
Author:     Jiri Olsa <jolsa <at> redhat.com>
AuthorDate: Fri Oct 23 19:36:17 2009 -0400
Committer:  Ingo Molnar <mingo <at> elte.hu>
CommitDate: Sat Oct 24 11:07:50 2009 +0200

    tracing: Fix trace_seq_printf() return value

    trace_seq_printf() return value is a little ambiguous. It
    currently returns the length of the space available in the
    buffer. printf usually returns the amount written. This is not
    adequate here, because:

      trace_seq_printf(s, "");

    is perfectly legal, and returning 0 would indicate that it
    failed.

    We can always see the amount written by looking at the before
    and after values of s->len. This is not quite the same use as
    printf. We only care if the string was successfully written to
    the buffer or not.

    Make trace_seq_printf() return 0 if the trace oversizes the
    buffer's free space, 1 otherwise.

    Signed-off-by: Jiri Olsa <jolsa <at> redhat.com>
    Signed-off-by: Steven Rostedt <rostedt <at> goodmis.org>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane