From: Mel Gorman
Commit 00442ad04a5e ("mempolicy: fix a memory corruption by refcount
imbalance in alloc_pages_vma()") changed get_vma_policy() to raise the
refcount on a shmem shared mempolicy; whereas shmem_alloc_page() went
on expecting alloc_page_vma() to drop the refcount it had acquired.
Th
# Sorry, I misspelled the e-mail address of stable@vger.kernel.org.
From: Al Viro
Subject: Re: [m32r] apparent roothole via PTRACE_SETREGS (kernel mode, even)
Date: Fri, 30 Nov 2012 14:54:35 +
> IOW, ptrace_write_user() is right - only ->psw.BC should be possible to
> modify and ->spi should
On Tue, 4 Dec 2012, Hugh Dickins wrote:
>
> Yes, your patch fixes it Mel, but I prefer it as below, with a couple
> of mods: removing the no longer true comment, and leaving shmem_swapin()
> alone with just a comment. It appears to be the job of the rather weird
> mpol_cond_copy() to drop the ref
On Tue, 4 Dec 2012, Mel Gorman wrote:
> On Tue, Dec 04, 2012 at 02:54:08PM +0200, Tommi Rantala wrote:
> > 2012/10/9 Mel Gorman :
> > > commit 00442ad04a5eac08a98255697c510e708f6082e2 upstream.
> > >
> > > Commit cc9a6c877661 ("cpuset: mm: reduce large amounts of memory barrier
> > > related damage
On 2012-12-04, at 13:24, Dave Chinner wrote:
> On Tue, Dec 04, 2012 at 01:56:39AM +0800, yangsheng wrote:
>> Relatime should update the inode atime if it is more than a day in the
>> future. The original problem seen was a tarball that had a bad atime,
>> but could also happen if someone fat-fing
- Original Message -
> From: "Dmitry Torokhov"
> To: "CAI Qian"
> Cc: stable@vger.kernel.org, krzys...@podlesie.net, pa...@ucw.cz
> Sent: Wednesday, December 5, 2012 2:53:43 AM
> Subject: Re: [PATCH] Input: mousedev - move /dev/input/mice to the correct
> minor
>
> On Tue, Dec 04, 201
于 2012年12月04日 03:10, Greg Kroah-Hartman 写道:
> On Mon, Dec 03, 2012 at 10:05:12PM +0300, Dan Carpenter wrote:
>> We get this from user space and nothing has been done to ensure that
>> these strings are NUL terminated.
>>
>> Cc: stable@vger.kernel.org
>> Reported-by: Chen Gang
>> Signed-off-by: Dan
On Tue, Dec 4, 2012 at 4:53 PM, wrote:
> From: Alex Deucher
>
> Need to use the adjusted mode since we are sending native
> timing and using the scaler for non-native modes.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> cc: stable@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/
From: Alex Deucher
Need to use the adjusted mode since we are sending native
timing and using the scaler for non-native modes.
Signed-off-by: Alex Deucher
cc: stable@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
On Mon, Dec 03, 2012 at 05:42:08PM -0600, Mark Tinguely wrote:
> Here a collection of bug fixes for 3.0-stable. Many of these patches
> were also selected by Dave Chinner as possible 3.0-stable patches:
> http://oss.sgi.com/archives/xfs/2012-08/msg00255.html
>
> I chose only bug fixes and ke
On Tue, Dec 04, 2012 at 01:56:39AM +0800, yangsheng wrote:
> Relatime should update the inode atime if it is more than a day in the
> future. The original problem seen was a tarball that had a bad atime,
> but could also happen if someone fat-fingers a "touch". The future
> atime will never be fi
On Tue, 4 Dec 2012 11:09:36 -0200 Herton Ronaldo Krzesinski
wrote:
> Hi, I got a request that following commit is good for stables. I also
> agree that is applicable. Can this be acked and if so queued to all
> stables? I verified that at least starting with 3.0 it should be
> applicable with min
On Tue, Dec 04, 2012 at 04:44:18AM -0500, CAI Qian wrote:
> When doing conversion to dynamic input numbers I inadvertently moved
> /dev/input/mice from c,13,63 to c,13,31. We need to fix this so that
> setups with statically populated /dev continue working.
>
> Tested-by: Krzysztof Mazur
> Tested
On 12/04/2012 02:34 AM, Heinz Wiesinger wrote:
On Monday 03 December 2012 15:14:12 you wrote:
On 11/05/2012 02:55 PM, Heinz Wiesinger wrote:
On Monday 05 November 2012 11:13:31 Greg KH wrote:
On Mon, Nov 05, 2012 at 01:11:18AM -0800, Jonathan Nieder wrote:
Hi,
In March, Greg KH wrote:
3.2-s
Em Tue, 04 Dec 2012 11:19:52 -0700
Shuah Khan escreveu:
> On Tue, 2012-12-04 at 09:41 -0200, Mauro Carvalho Chehab wrote:
> > Em 03-12-2012 22:26, Prarit Bhargava escreveu:
> > >
> > >
> > > On 12/03/2012 07:03 PM, Shuah Khan wrote:
> > >> Prarit/Mauro,
> > >>
> > >> Should this patch go into sta
On Tue, 2012-12-04 at 09:41 -0200, Mauro Carvalho Chehab wrote:
> Em 03-12-2012 22:26, Prarit Bhargava escreveu:
> >
> >
> > On 12/03/2012 07:03 PM, Shuah Khan wrote:
> >> Prarit/Mauro,
> >>
> >> Should this patch go into stables as well?
> >
> > I have no objection to it going to stable, but will
inet_getpeer_v4() can return NULL under OOM conditions, and while
inet_peer_xrlim_allow() is OK with a NULL peer, inet_putpeer() will
crash.
This code path now uses the same idiom as the others from:
1d861aa4b3fb08822055345f480850205ffe6170 ("inet: Minimize use of
cached route inetpeer.").
Upstre
When a low-level comedi driver auto-configures a device, a `struct
comedi_dev_file_info` is allocated (as well as a `struct
comedi_device`) by `comedi_alloc_board_minor()`. A pointer to the
hardware `struct device` is stored as a cookie in the `struct
comedi_dev_file_info`. When the low-level com
On Mon, Dec 3, 2012 at 6:40 PM, Deucher, Alexander
wrote:
>> > The original patches should go into 3.6 kernels as well:
>> >
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4
>> a15903db02026728d0cf2755c6fabae16b8db6a
>> >
>> http://git.kernel.org/?p=linux/kernel/git
On Tue, Dec 04, 2012 at 02:54:08PM +0200, Tommi Rantala wrote:
> 2012/10/9 Mel Gorman :
> > commit 00442ad04a5eac08a98255697c510e708f6082e2 upstream.
> >
> > Commit cc9a6c877661 ("cpuset: mm: reduce large amounts of memory barrier
> > related damage v3") introduced a potential memory corruption.
>
On 04.12.12 11:42:58, Herton Ronaldo Krzesinski wrote:
> Hi, this makes build fail with oprofile on i386 on 3.0.54:
> ERROR: "kernel_stack_pointer" [arch/x86/oprofile/oprofile.ko] undefined!
>
> The following commit should address this failure:
>
> commit cb57a2b4cff7edf2a4e32c0163200e9434807e0a
On Fri, Nov 30, 2012 at 10:55:01AM -0800, Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Robert Richter
>
> commit 1022623842cb72ee4d0dbf02f6937f38c92c3f41 upstream.
>
> In 32 bit the stack address provid
On Fri, Nov 30, 2012 at 10:45:53AM -0800, Greg Kroah-Hartman wrote:
> 3.0-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Robert Richter
>
> commit 1022623842cb72ee4d0dbf02f6937f38c92c3f41 upstream.
>
> In 32 bit the stack address provid
Hi, I got a request that following commit is good for stables. I also
agree that is applicable. Can this be acked and if so queued to all
stables? I verified that at least starting with 3.0 it should be
applicable with minor adjusting, 3.2 onwards should cherry-pick cleanly:
commit bc78c57388e7f44
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: i7300_edac: Fix error flag testing
Author: Jean Delvare
Date:Thu Oct 18 15:54:45 2012 +0200
* Right-shift the values in GET_FBD_FAT_IDX and
2012/10/9 Mel Gorman :
> commit 00442ad04a5eac08a98255697c510e708f6082e2 upstream.
>
> Commit cc9a6c877661 ("cpuset: mm: reduce large amounts of memory barrier
> related damage v3") introduced a potential memory corruption.
> shmem_alloc_page() uses a pseudo vma and it has one significant unique
>
Mauro Carvalho Chehab writes:
> It seems ok to send it to stable for the stable versions that got the
> HERM patches (e. g. EDAC core version updated to 3.0.0). Adding it
> to older ones would cause regressions.
>
> In other words, if the following patch exists at -stable, then
> I recommend back
Em 03-12-2012 22:26, Prarit Bhargava escreveu:
On 12/03/2012 07:03 PM, Shuah Khan wrote:
Prarit/Mauro,
Should this patch go into stables as well?
I have no objection to it going to stable, but will leave the final decision to
Mauro.
It seems ok to send it to stable for the stable versions
Stable-3.0 commit 42ab5316 (ipv4: fix redirect handling) was
backport of mainline commit 9cc20b26 from 3.2-rc3 where hh
member of struct dst_entry was already gone.
However, in 3.0 we still have it and we have to clean it as
well, otherwise it keeps pointing to the cleaned up (and
unusable) hh_cac
On Monday 03 December 2012 15:14:12 you wrote:
> On 11/05/2012 02:55 PM, Heinz Wiesinger wrote:
> > On Monday 05 November 2012 11:13:31 Greg KH wrote:
> >> On Mon, Nov 05, 2012 at 01:11:18AM -0800, Jonathan Nieder wrote:
> >>> Hi,
> >>>
> >>> In March, Greg KH wrote:
> 3.2-stable review patch
This patch reverts b01af4579ec41f48e9b9c774e70bd6474ad210db.
The original patch was tested with emulated hardware. Real
hardware chokes.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=47041
Signed-off-by: Francois Romieu
Acked-by: Jeff Garzik
Signed-off-by: David S. Miller
Upstream-ID: b2
When doing conversion to dynamic input numbers I inadvertently moved
/dev/input/mice from c,13,63 to c,13,31. We need to fix this so that
setups with statically populated /dev continue working.
Tested-by: Krzysztof Mazur
Tested-by: Pavel Machek
Signed-off-by: Dmitry Torokhov
Upstream-ID: c91cb
Patch sets the lowest gso_max_size and gso_max_segs values of the slave devices
during enslave and detach.
Signed-off-by: Sarveshwar Bandi
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Upstream-ID: 0e376bd0b791ac6ac6bdb051492df0769c840848
Stable-trees: 3.0.x, 3.4.x, 3.6.x
Signed-off-b
Select HAVE_ALIGNED_STRUCT_PAGE on s390, so that the slub allocator can make
use of compare and swap double for lockless updates. This increases the size
of struct page to 64 bytes (instead of 56 bytes), however the performance gain
justifies the increased size:
- now excactly four struct pages fi
Select HAVE_ALIGNED_STRUCT_PAGE on s390, so that the slub allocator can make
use of compare and swap double for lockless updates. This increases the size
of struct page to 64 bytes (instead of 56 bytes), however the performance gain
justifies the increased size:
- now excactly four struct pages fi
35 matches
Mail list logo
