We need this for dp aux communication. This issue can fill the dmesg
with WARN spam when the panel is disable (e.g. while reconfiguring the
mode or while resuming).
v2: Actually enable edp vdd early enough. I've missed one dp aux
channel thingy ...
v3: We also enable/disable vdd in get_edid, whic
Spotted while reviewing the same patch for drm/via by Németh Márton.
Cc: stable@vger.kernel.org
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/sis/sis_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c
inde
From: KOSAKI Motohiro
Hi
This is trivial fixes of mempolicy meory corruption issues. There
are independent patches each ather. and, they don't change userland
ABIs.
Thanks.
changes from v1: fix some typo of changelogs.
---
KOSAKI Motohiro (6):
Rev
From: KOSAKI Motohiro
commit 05f144a0d5 "mm: mempolicy: Let vma_merge and vma_split handle
vma->vm_policy linkages" removed a vma->vm_policy updates. But it is
a primary purpose of mbind_range(). Now, mbind(2) is no-op in several
case unintentionally. It is not ideal fix. This patch reverts it.
From: KOSAKI Motohiro
Dave Jones' system call fuzz testing tool "trinity" triggered the following
bug error with slab debugging enabled
[ 7613.229315]
=
[ 7613.229955] BUG numa_policy (Not tainted): Poison overwritten
[
From: KOSAKI Motohiro
shared_policy_replace() uses sp_alloc() wrongly. 1) sp_node can't be
dereferenced when
not holding sp->lock and 2) another thread can modify sp_node when sp->lock is
unlocked.
This patch fixes them.
Note: The bug was introduced pre-git age (IOW, before 2.6.12-rc2). I bel
From: KOSAKI Motohiro
When shared_policy_replace() failure, new->policy is not freed correctly.
The real problem is, shared mempolicy codes directly call kmem_cache_free()
in multiple place.
This patch creates proper wrapper function and uses it.
Note: The bug was introduced pre-git age (IOW, be
From: KOSAKI Motohiro
commit cc9a6c8776 (cpuset: mm: reduce large amounts of memory barrier related
damage v3) introduced a memory corruption.
shmem_alloc_page() passes pseudo vma and it has one significant unique
combination, vma->vm_ops=NULL and (vma->policy->flags & MPOL_F_SHARED).
Now, get_
From: KOSAKI Motohiro
Signed-off-by: KOSAKI Motohiro
Acked-by: Christoph Lameter
---
MAINTAINERS |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a246490..6f4a8e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4467,6 +4467,13 @@ F:
On Sun, 20 May 2012, David Rientjes wrote:
> Agreed, slab handles this correctly and it looks like slub ends up
> disabling irqs too early.
>
> Does this fix it? If so, we'll need to annotate it for stable as Ben
> noted.
>
Steven, did you have a chance to see if this fixes the issue for you
(2012/06/08 21:18), Oleg Nesterov wrote:
On 06/07, Linus Torvalds wrote:
It does totally insane things in xacct_add_tsk(). You can't call
"sync_mm_rss(mm)" on somebody elses mm,
Damn, I am stupid. Yes, I forgot about fill_stats_for_pid().
And I didn't bother to look at get_task_mm() which cle
- Original Message -
> On Thu, Jun 07, 2012 at 11:00:33PM +0200, Andrea Arcangeli wrote:
> > In the x86 32bit PAE CONFIG_TRANSPARENT_HUGEPAGE=y case while
> > holding
> > the mmap_sem for reading, cmpxchg8b cannot be used to read pmd
> > contents under Xen.
> >
> > So instead of dealing
On Mon, Jun 11, 2012 at 02:56:03AM -0700, David Rientjes wrote:
> On Sun, 20 May 2012, David Rientjes wrote:
>
> > Agreed, slab handles this correctly and it looks like slub ends up
> > disabling irqs too early.
> >
> > Does this fix it? If so, we'll need to annotate it for stable as Ben
> > n
On Mon, 2012-06-11 at 14:23 +0800, Huang Ying wrote:
> This patch fixed the following bug.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=43282
>
> This is caused by a firmware bug checking (checking generic address
> register provided by firmware) in runtime. The checking should be
> done in a
On Mon, 2012-06-11 at 05:17 -0400, kosaki.motoh...@gmail.com wrote:
> From: KOSAKI Motohiro
>
> commit cc9a6c8776 (cpuset: mm: reduce large amounts of memory barrier related
> damage v3) introduced a memory corruption.
>
> shmem_alloc_page() passes pseudo vma and it has one significant unique
>
Richard,
fyi - this error in lpfc was corrected in our 8.3.31 patch set - posted
back in May:
http://www.spinics.net/lists/linux-scsi/msg59216.html
-- james
On 6/7/2012 2:42 AM, Jonathan Nieder wrote:
Richard Yao wrote:
Using -Werror enables us to catch potential runtime issues before the
On Mon, 11 Jun 2012, Ming Lei wrote:
> @@ -1820,6 +1833,18 @@ void device_shutdown(void)
> list_del_init(&dev->kobj.entry);
> spin_unlock(&devices_kset->list_lock);
>
> + /* hold lock to avoid race with .probe/.release */
> + if (dev->parent &&
On Mon, Jun 11, 2012 at 10:16 PM, Alan Stern wrote:
>> +
>> + if (nonlocked)
>> + dev_err(dev, "can't hold %slock for shutdown\n",
>> + nonlocked == 1 ? "" : "parent ");
>
> Even if the parent can't be locked, you should still tr
On Mon, 11 Jun 2012, kosaki.motoh...@gmail.com wrote:
> From: KOSAKI Motohiro
>
> commit 05f144a0d5 "mm: mempolicy: Let vma_merge and vma_split handle
> vma->vm_policy linkages" removed a vma->vm_policy updates. But it is
> a primary purpose of mbind_range(). Now, mbind(2) is no-op in several
> c
On Mon, 11 Jun 2012, kosaki.motoh...@gmail.com wrote:
> changes from v1: fix some typo of changelogs.
I still have a hard time with the changelogs. Will try to give you
hopefulyl better ones.
Again you need to CC Andi Kleen on this. He wrote most of the shared
mempolicy code (long time ago) and
Some more attempts to cleanup changelogs:
> The problem was created by a reference count imbalance. Example, In following
> case,
> mbind(addr, len) try to replace mempolicies of vma1 and vma2 and then they
> will
> be share the same mempolicy, and the new mempolicy has MPOL_F_SHARED flag.
The
(6/11/12 9:33 AM), Ben Hutchings wrote:
On Mon, 2012-06-11 at 05:17 -0400, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro
commit cc9a6c8776 (cpuset: mm: reduce large amounts of memory barrier related
damage v3) introduced a memory corruption.
shmem_alloc_page() passes pseudo vma and it
commit: 7c8d51848a88aafdb68f42b6b650c83485ea2f84
From: Mathias Krause
Date: Wed, 30 May 2012 01:43:08 +0200
Subject: crypto: aesni-intel - fix unaligned cbc decrypt for x86-32
The 32 bit variant of cbc(aes) decrypt is using instructions requiring
128 bit aligned memory locations but fails to ensu
commit: 121daad8fd1dce63076fa55aaedd5dc3f981b334
From: Peter Korsgaard
Date: Thu, 31 May 2012 20:53:08 +1000
Subject: hwrng: atmel-rng - fix race condition leading to repeated bits
Data valid gets cleared by reading the ISR (status register) and NOT from
reading ODATA (data register). A new data
This is a note to let you know that I've just added the patch titled
crypto: aesni-intel - fix unaligned cbc decrypt for x86-32
to the 3.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
crypto: aesni-intel - fix unaligned cbc decrypt for x86-32
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
hwrng: atmel-rng - fix race condition leading to repeated bits
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is
On Mon, 11 Jun 2012, Ming Lei wrote:
> On Mon, Jun 11, 2012 at 10:16 PM, Alan Stern
> wrote:
>
> >> +
> >> + � � � � � � if (nonlocked)
> >> + � � � � � � � � � � dev_err(dev, "can't hold %slock for shutdown\n",
> >> + � � � � � � � � � � � � � � � � � � nonlocked == 1 ? "" : "parent ");
> >
>
On 05/23/2012 03:00 PM, Nicolas Ferre :
> On 05/23/2012 02:31 PM, Peter Korsgaard :
>> Brown paper bag: Data valid is LSB of the ISR (status register), and NOT
>> of ODATA (current random data word)!
>>
>> With this, rngtest is a lot happier. Before:
>>
>> rngtest 3
>> Copyright (c) 2004 by Henriqu
On 10.06.12 00:50:15, gre...@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> x86, MCE, AMD: Make APIC LVT thresholding interrupt optional
>
> to the 3.4-stable tree which can be found at:
>
> http://www.kernel.org/git/?p=linux/kern
On Sun, 27 May 2012 09:53:14 +0900
Greg KH wrote:
> On Mon, May 21, 2012 at 05:25:16PM -0700, Stephen Hemminger wrote:
> > Users of 3.0 kernel on Dell with 32 bit kernels see:
> >
> > [Firmware Warn]: GHES: Failed to read error status block address for
> > hardware error source: 49376.
> >
On Mon, Jun 11, 2012 at 07:20:21PM +0200, Robert Richter wrote:
> On 10.06.12 00:50:15, gre...@linuxfoundation.org wrote:
> >
> > This is a note to let you know that I've just added the patch titled
> >
> > x86, MCE, AMD: Make APIC LVT thresholding interrupt optional
> >
> > to the 3.4-stabl
> > Nice. Andrew, any chane you could test this patch on the affected
> > Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
> > hypervisor or is it really only on Linode and Amazon EC2?
> >
>
> Originally, I was able to reproduce the issue easily with a RHEL5
> host. Now, with th
Hi,
On Mon, Jun 11, 2012 at 03:27:38PM -0400, Konrad Rzeszutek Wilk wrote:
> > > Nice. Andrew, any chane you could test this patch on the affected
> > > Xen hypervisors? Was it as easy to reproduce this on a RHEL5 (U1?)
> > > hypervisor or is it really only on Linode and Amazon EC2?
> > >
> >
>
On Sat, Jun 9, 2012 at 5:07 AM, Mark Brown
wrote:
> Not paying attention to the value being set is a bad thing because it
> means that we'll not set the hardware up to reflect what was requested.
> Not setting the hardware up to reflect what was requested means that the
> caller won't get the res
The patch titled
Subject: nilfs2: ensure proper cache clearing for gc-inodes
has been added to the -mm tree. Its filename is
nilfs2-ensure-proper-cache-clearing-for-gc-inodes.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a
The patch titled
From: Konstantin Khlebnikov
has been added to the -mm tree. Its filename is
mm-correctly-synchronize-rss-counters-at-exit-exec.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
This is a note to let you know that I've just added the patch titled
staging: usbip: bugfix for stack corruption on 64-bit architectures
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch w
On Mon, Jun 11, 2012 at 06:15:53PM +0200, Nicolas Ferre wrote:
>
> It seems that this patch did not make it in your tree before the "other
> one" from Peter: in linus' tree: 121daad (hwrng: atmel-rng - fix race
> condition leading to repeated bits).
>
> So, do you want me to rebase this patch bec
On Tue, Jun 12, 2012 at 12:02 AM, Alan Stern wrote:
> On Mon, 11 Jun 2012, Ming Lei wrote:
>>
>> I have considered doing it, but which may consume another 1sec.
>>
>> Also if the parent lock has been held, it is very possibly that the
>> device can't be probed or removed at the same time, so just
On Mon, Jun 11, 2012 at 05:04:36PM -0700, gre...@linuxfoundation.org wrote:
[...]
> From: Bart Westgeest
> Date: Mon, 11 Jun 2012 12:13:08 -0400
> Subject: staging: usbip: bugfix for stack corruption on 64-bit architectures
>
> Previously a 6 byte array (buf) was erroneously cast to a 8 byte long
On Mon, 2012-06-11 at 14:25 +0100, Ben Hutchings wrote:
> On Mon, 2012-06-11 at 14:23 +0800, Huang Ying wrote:
> > This patch fixed the following bug.
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=43282
> >
> > This is caused by a firmware bug checking (checking generic address
> > register
This patch fixed the following bug.
https://bugzilla.kernel.org/show_bug.cgi?id=43282
This is caused by a firmware bug checking (checking generic address
register provided by firmware) in runtime. The checking should be
done in address mapping time instead of runtime to avoid too much
error repo
applied.
thanks,
-Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
44 matches
Mail list logo
