David Laight wrote...
> A full wrap might catch checks for less than (say) 4.4.2 which
> might be present to avoid very early versions.
> So sticking at 255 or wrapping onto (say) 128 to 255 might be better.
Hitting such version checks still might happen, though.
Also, any wrapping introduces a
Greg Kroah-Hartman wrote...
> 4.20-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Greg Kroah-Hartman
>
> This reverts commit d412deb85a4aada382352a8202beb7af8921cd53 which is
> commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.
>
>
Greg Kroah-Hartman wrote...
> Ok, Breno and Christoph, what should I do here? Should I drop this
> patch in the tree or add this new one? Ideally I can fix this soon as I
> don't like having broken trees out there...
Whatever Breno says - I don't feel competent enough to decide what's
right her
Christoph Biedl wrote...
> Sorry for not getting back to you earlier. Building yesterday's
> release (v4.19.14) *failed*, bisect led to
>
> | commit a9935a12768851762089fda8e5a9daaf0231808e (HEAD)
> | Author: Breno Leitao
> | Date: Mon Nov 26 18:12:00 2018 -0200
> |
Greg Kroah-Hartman wrote...
> I dropped e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint")
> from the stable trees, which is what I was told was the commit that was
> causing the problems by Christoph and Breno (on to: now).
>
> Was that not the offending commit? If so, what one
Greg Kroah-Hartman wrote...
> On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote:
> > > commit 3c181c12c431fe33b669410d663beb9cceefcd1b upstream.
> > On big-endian systems, this change intruduces severe corruption,
> > resulting in complete loss of the data
Greg Kroah-Hartman wrote...
> 4.14-stable review patch. If anyone has any objections, please let me know.
> commit 3c181c12c431fe33b669410d663beb9cceefcd1b upstream.
(...)
> If the filesystem is always used on a same endian host, this will not
> be a problem.
>From my observations I cannot qui
Maxime Ripard wrote...
> > > > This patch specifiy statesize for sha1 and md5.
> > > >
> > > > Signed-off-by: LABBE Corentin
> > > > Cc: sta...@vger.kernel.org
> > >
> > > Please also add a Fixes tag (and the stable version it applies to).
> >
> > I don't see the point for a fixes tag as it wo
Eric Dumazet wrote...
[ commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af ]
> It definitely should help !
Yesterday, I've experienced issues somewhat similar to this, but I'm
not entirely sure:
Four of five systems running 4.1.9 stopped working. No reaction on
network, keyboard, serial console. I
Willy Tarreau wrote...
> Initialize event_data for all possible message types to prevent leaking
> kernel stack contents to userland (up to 20 bytes). Also set the flags
> member of the connector message to 0 to prevent leaking two more stack
> bytes this way.
There are build errors as shown belo
Khalid Aziz wrote...
> Better yet, just pull this patch from stable from now. I will redo
> the patch and send another one for the next round.
FYI, after patching mm/swap.c accordingly, all the 3.0 and 3.4
configurations I use do build. Some boot tests will follow, I'll
follow up only if I see un
Khalid Aziz wrote...
> Thanks for tracking this down. I had not tried a configuration with
> CONFIG_HUGETLB_PAGE not set. In my config, I was getting many
> multiple definition errors for bunch of other defines from
> linux/hugetlb.h. I will look at my config again but chances are I
> had somethin
Guenter Roeck wrote...
> On 10/02/2013 09:04 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.0.99 release.
> Heads up: I am getting lots of build failures in 3.0 and 3.4 builds.
>
> mm/built-in.o: In function `__put_compound_page':
> slab.c:(.text+0xaa3c):
Willy Tarreau wrote...
> I'm attaching the two patches here to be appled on top of 2.6.32.61, I would
> like it if you could try in your environment to confirm that they correctly
> fix the issue.
Confirmation: Kernel builds and runs for both Debian squeeze and
wheezy (gcc 4.4 and gcc 4.7) on i38
Greg Kroah-Hartman wrote...
> 3.6-stable review patch. If anyone has any objections, please let me know.
Only a small set of the (guessed) 300 e-mails arrived here, they were:
- 21/11 Greg Kroah-Hartman ┬─>[ 81/83] ACPI video: Ignore errors after _DOD
evaluation.
- 21/11 Greg Kroah-Hartman
John Stultz wrote...
> Attached is the test case I used to reproduce and test the solution
> to the hard-hang deadlock.
I was wondering whether anybody managed to crash a virtualbox guest
using your program. No avail, using version 4.1.18 on the host and the
guest kernel running several 3.0.x (x
Hi,
There are ITE 8212-based controllers installed in some of my
computers. I had always skipped the build-in RAID things and used them
as plain controllers.
1. Beginning with 2.6.18 there was some trouble, basically slowed data
transfer, sometimes even a totally stalled system (I cannot reproduc
17 matches
Mail list logo
