Re: [ANNOUNCE] Linux 3.11.y.z extended stable support

[Luis Henriques]

Hi Josh,

On Mon, Dec 02, 2013 at 02:58:31PM -0500, Josh Boyer wrote:
> On Mon, Dec 2, 2013 at 10:43 AM, Luis Henriques
>  wrote:
> > Since Ubuntu 13.10 "Saucy Salamander" uses the 3.11 kernel, the Ubuntu
> > kernel team will pick up stable maintenance where Greg KH left off[1]
> > with 3.11.10 (thanks a lot, Greg!).
> >
> > The Ubuntu kernel team is pleased to announce that we will be
> > providing extended stable support for the Linux 3.11 kernel until
> > August 2014 as a third party effort maintained on our infrastructure.
> >
> > Our linux-3.11.y{-queue,-review} stable branches will fork from
> > 3.11.10 and will be published here:
> >
> > git://kernel.ubuntu.com/ubuntu/linux.git
> >
> > We will use the same stable request/review workflow and follow the
> > standard upstream stable kernel rules.  More details are available at
> > http://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
> >
> > We welcome any feedback and contribution to this effort.  We will be
> > posting the first review cycle patch set in a week or two.
> 
> I might have asked this already before, but if I did I've forgotten
> the answer.  Apologies if so.
> 
> Why not do this on the kernel.org infrastructure and treat it like all
> the other kernel.org stable releases?  I'm confused why it needs to be
> "forked" when it's following the same rules.  It seems like it could
> just pick up with 3.11.11 and carry on.

I would be more than happy to maintain the 3.11 kernel using Greg's
official stable git repository (e.g., by sending him a pull request).
However, I believe this has been proposed in the past without
success.

Anyway, we're still open to change this.  Greg, please let me know if
you would like to have the 3.11 kernel maintained for some more time,
or if you rather keep it dead.

Cheers,
--
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Linux 3.11.y.z extended stable support

[Luis Henriques]

Hi Josh,

On Mon, Dec 02, 2013 at 02:58:31PM -0500, Josh Boyer wrote:
 On Mon, Dec 2, 2013 at 10:43 AM, Luis Henriques
 luis.henriq...@canonical.com wrote:
  Since Ubuntu 13.10 Saucy Salamander uses the 3.11 kernel, the Ubuntu
  kernel team will pick up stable maintenance where Greg KH left off[1]
  with 3.11.10 (thanks a lot, Greg!).
 
  The Ubuntu kernel team is pleased to announce that we will be
  providing extended stable support for the Linux 3.11 kernel until
  August 2014 as a third party effort maintained on our infrastructure.
 
  Our linux-3.11.y{-queue,-review} stable branches will fork from
  3.11.10 and will be published here:
 
  git://kernel.ubuntu.com/ubuntu/linux.git
 
  We will use the same stable request/review workflow and follow the
  standard upstream stable kernel rules.  More details are available at
  http://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
 
  We welcome any feedback and contribution to this effort.  We will be
  posting the first review cycle patch set in a week or two.
 
 I might have asked this already before, but if I did I've forgotten
 the answer.  Apologies if so.
 
 Why not do this on the kernel.org infrastructure and treat it like all
 the other kernel.org stable releases?  I'm confused why it needs to be
 forked when it's following the same rules.  It seems like it could
 just pick up with 3.11.11 and carry on.

I would be more than happy to maintain the 3.11 kernel using Greg's
official stable git repository (e.g., by sending him a pull request).
However, I believe this has been proposed in the past without
success.

Anyway, we're still open to change this.  Greg, please let me know if
you would like to have the 3.11 kernel maintained for some more time,
or if you rather keep it dead.

Cheers,
--
Luis
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] Linux 3.11.y.z extended stable support

[Josh Boyer]

On Mon, Dec 2, 2013 at 10:43 AM, Luis Henriques
 wrote:
> Since Ubuntu 13.10 "Saucy Salamander" uses the 3.11 kernel, the Ubuntu
> kernel team will pick up stable maintenance where Greg KH left off[1]
> with 3.11.10 (thanks a lot, Greg!).
>
> The Ubuntu kernel team is pleased to announce that we will be
> providing extended stable support for the Linux 3.11 kernel until
> August 2014 as a third party effort maintained on our infrastructure.
>
> Our linux-3.11.y{-queue,-review} stable branches will fork from
> 3.11.10 and will be published here:
>
> git://kernel.ubuntu.com/ubuntu/linux.git
>
> We will use the same stable request/review workflow and follow the
> standard upstream stable kernel rules.  More details are available at
> http://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
>
> We welcome any feedback and contribution to this effort.  We will be
> posting the first review cycle patch set in a week or two.

I might have asked this already before, but if I did I've forgotten
the answer.  Apologies if so.

Why not do this on the kernel.org infrastructure and treat it like all
the other kernel.org stable releases?  I'm confused why it needs to be
"forked" when it's following the same rules.  It seems like it could
just pick up with 3.11.11 and carry on.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] Linux 3.11.y.z extended stable support

[Luis Henriques]

Since Ubuntu 13.10 "Saucy Salamander" uses the 3.11 kernel, the Ubuntu
kernel team will pick up stable maintenance where Greg KH left off[1]
with 3.11.10 (thanks a lot, Greg!).

The Ubuntu kernel team is pleased to announce that we will be
providing extended stable support for the Linux 3.11 kernel until
August 2014 as a third party effort maintained on our infrastructure.

Our linux-3.11.y{-queue,-review} stable branches will fork from
3.11.10 and will be published here:

git://kernel.ubuntu.com/ubuntu/linux.git

We will use the same stable request/review workflow and follow the
standard upstream stable kernel rules.  More details are available at
http://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

We welcome any feedback and contribution to this effort.  We will be
posting the first review cycle patch set in a week or two.

[1] https://lkml.org/lkml/2013/11/29/327

--
Luis Henriques
Ubuntu Kernel Team, Canonical Ltd.


pgp4rj7kpGvcQ.pgp
Description: PGP signature

[ANNOUNCE] Linux 3.11.y.z extended stable support

[Luis Henriques]

Since Ubuntu 13.10 Saucy Salamander uses the 3.11 kernel, the Ubuntu
kernel team will pick up stable maintenance where Greg KH left off[1]
with 3.11.10 (thanks a lot, Greg!).

The Ubuntu kernel team is pleased to announce that we will be
providing extended stable support for the Linux 3.11 kernel until
August 2014 as a third party effort maintained on our infrastructure.

Our linux-3.11.y{-queue,-review} stable branches will fork from
3.11.10 and will be published here:

git://kernel.ubuntu.com/ubuntu/linux.git

We will use the same stable request/review workflow and follow the
standard upstream stable kernel rules.  More details are available at
http://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

We welcome any feedback and contribution to this effort.  We will be
posting the first review cycle patch set in a week or two.

[1] https://lkml.org/lkml/2013/11/29/327

--
Luis Henriques
Ubuntu Kernel Team, Canonical Ltd.


pgp4rj7kpGvcQ.pgp
Description: PGP signature

Re: [ANNOUNCE] Linux 3.11.y.z extended stable support

[Josh Boyer]

On Mon, Dec 2, 2013 at 10:43 AM, Luis Henriques
luis.henriq...@canonical.com wrote:
 Since Ubuntu 13.10 Saucy Salamander uses the 3.11 kernel, the Ubuntu
 kernel team will pick up stable maintenance where Greg KH left off[1]
 with 3.11.10 (thanks a lot, Greg!).

 The Ubuntu kernel team is pleased to announce that we will be
 providing extended stable support for the Linux 3.11 kernel until
 August 2014 as a third party effort maintained on our infrastructure.

 Our linux-3.11.y{-queue,-review} stable branches will fork from
 3.11.10 and will be published here:

 git://kernel.ubuntu.com/ubuntu/linux.git

 We will use the same stable request/review workflow and follow the
 standard upstream stable kernel rules.  More details are available at
 http://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

 We welcome any feedback and contribution to this effort.  We will be
 posting the first review cycle patch set in a week or two.

I might have asked this already before, but if I did I've forgotten
the answer.  Apologies if so.

Why not do this on the kernel.org infrastructure and treat it like all
the other kernel.org stable releases?  I'm confused why it needs to be
forked when it's following the same rules.  It seems like it could
just pick up with 3.11.11 and carry on.

josh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unnecessary mass OOM kills on Linux 3.11 virtualization host

[Richard Davies]

Dave Hansen wrote:
> Richard Davies wrote:
> > I further attach some other types of memory manager errors found in the
> > kernel logs around the same time. There are several occurrences of each, but
> > I have only copied one here for brevity:
> >
> > 19:18:27 kernel: BUG: Bad page map in process qemu-system-x86  pte:0608 
> > pmd:1d57fd067
>
> FWIW, I took a quick look through your OOM report and didn't see any
> obvious causes for it.  But, INMHO, you should probably ignore the OOM
> issue until you've fixed these "Bad page map" problems.   Those are a
> sign of a much deeper problem.

Thanks! What investigation should I do for these? It is on stock 3.11.3.

Richard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unnecessary mass OOM kills on Linux 3.11 virtualization host

[Dave Hansen]

On 10/28/2013 01:28 AM, Richard Davies wrote:
> I further attach some other types of memory manager errors found in the
> kernel logs around the same time. There are several occurrences of each, but
> I have only copied one here for brevity:
> 
> 19:18:27 kernel: BUG: Bad page map in process qemu-system-x86  pte:0608 
> pmd:1d57fd067

FWIW, I took a quick look through your OOM report and didn't see any
obvious causes for it.  But, INMHO, you should probably ignore the OOM
issue until you've fixed these "Bad page map" problems.   Those are a
sign of a much deeper problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unnecessary mass OOM kills on Linux 3.11 virtualization host

[Dave Hansen]

On 10/28/2013 01:28 AM, Richard Davies wrote:
 I further attach some other types of memory manager errors found in the
 kernel logs around the same time. There are several occurrences of each, but
 I have only copied one here for brevity:
 
 19:18:27 kernel: BUG: Bad page map in process qemu-system-x86  pte:0608 
 pmd:1d57fd067

FWIW, I took a quick look through your OOM report and didn't see any
obvious causes for it.  But, INMHO, you should probably ignore the OOM
issue until you've fixed these Bad page map problems.   Those are a
sign of a much deeper problem.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unnecessary mass OOM kills on Linux 3.11 virtualization host

[Richard Davies]

Dave Hansen wrote:
 Richard Davies wrote:
  I further attach some other types of memory manager errors found in the
  kernel logs around the same time. There are several occurrences of each, but
  I have only copied one here for brevity:
 
  19:18:27 kernel: BUG: Bad page map in process qemu-system-x86  pte:0608 
  pmd:1d57fd067

 FWIW, I took a quick look through your OOM report and didn't see any
 obvious causes for it.  But, INMHO, you should probably ignore the OOM
 issue until you've fixed these Bad page map problems.   Those are a
 sign of a much deeper problem.

Thanks! What investigation should I do for these? It is on stock 3.11.3.

Richard.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Disabling in-memory write cache for x86-64 in Linux 3.11

[Artem S. Tashkinov]

Hello,

On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
built for the i686 (with PAE) and x86-64 architectures. What's really troubling 
me
is that the x86-64 kernel has the following problem:

When I copy large files to any storage device, be it my HDD with ext4 partitions
or flash drive with FAT32 partitions, the kernel first caches them in memory 
entirely
then flushes them some time later (quite unpredictably though) or immediately 
upon
running "sync".

How can I disable this memory cache altogether? When running the i686 kernel 
with
the same configuration I don't observe this effect - files get written out 
almost immediately
(for instance "sync" takes less than a second, whereas on x86-64 it can take a 
dozen of
_minutes_ depending on a file size and storage performance).

I'm _not_ talking about disabling write cache on my storage itself (hdparm -W 0 
/dev/XXX)
- firstly this command is detrimental to the performance of my PC, secondly, it 
won't help
in this instance.

Swap is totally disabled, usually my memory is entirely free.

My kernel configuration can be fetched here: 
https://bugzilla.kernel.org/show_bug.cgi?id=63531

Please, advise.

Best regards,

Artem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Disabling in-memory write cache for x86-64 in Linux 3.11

[Artem S. Tashkinov]

Hello,

On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 kernel
built for the i686 (with PAE) and x86-64 architectures. What's really troubling 
me
is that the x86-64 kernel has the following problem:

When I copy large files to any storage device, be it my HDD with ext4 partitions
or flash drive with FAT32 partitions, the kernel first caches them in memory 
entirely
then flushes them some time later (quite unpredictably though) or immediately 
upon
running sync.

How can I disable this memory cache altogether? When running the i686 kernel 
with
the same configuration I don't observe this effect - files get written out 
almost immediately
(for instance sync takes less than a second, whereas on x86-64 it can take a 
dozen of
_minutes_ depending on a file size and storage performance).

I'm _not_ talking about disabling write cache on my storage itself (hdparm -W 0 
/dev/XXX)
- firstly this command is detrimental to the performance of my PC, secondly, it 
won't help
in this instance.

Swap is totally disabled, usually my memory is entirely free.

My kernel configuration can be fetched here: 
https://bugzilla.kernel.org/show_bug.cgi?id=63531

Please, advise.

Best regards,

Artem
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ARM/Samsung/S3C24xx: Linux-3.11 crashes when using PWM

[Jürgen Beisert]

Hi Sylwester,

On Wednesday 25 September 2013 11:18:52 Sylwester Nawrocki wrote:
> On 25/09/13 10:29, Jürgen Beisert wrote:
> > Change one single line:
> >
> > diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c
> > b/arch/arm/mach-s3c24xx/mach-mini2440.c index a83db46..d8273da 100644
> > --- a/arch/arm/mach-s3c24xx/mach-mini2440.c
> > +++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
> > @@ -519,6 +519,7 @@ static struct platform_device *mini2440_devices[]
> > __initdata = { _device_iis,
> > _codec,
> > _audio,
> > +   _device_timer[0],
> >  };
>
> I think you need to add instead:
>
>   _device_pwm,
>
> IIRC I had this working, can't verify at the moment as I don't
> have access to the board right now. Please see commit:
>
> 7fa33bdb4c44155e390c9ebbc5aa4c5cfc73f6fa
> ARM: SAMSUNG: Modify board files to use new PWM platform device

Seems valid for 3.12, but not for 3.11.

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ARM/Samsung/S3C24xx: Linux-3.11 crashes when using PWM

[Sylwester Nawrocki]

Hi Jürgen,

On 25/09/13 10:29, Jürgen Beisert wrote:
> Change one single line:
> 
> diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c 
> b/arch/arm/mach-s3c24xx/mach-mini2440.c
> index a83db46..d8273da 100644
> --- a/arch/arm/mach-s3c24xx/mach-mini2440.c
> +++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
> @@ -519,6 +519,7 @@ static struct platform_device *mini2440_devices[] 
> __initdata = {
> _device_iis,
> _codec,
> _audio,
> +   _device_timer[0],
>  };

I think you need to add instead:

_device_pwm,

IIRC I had this working, can't verify at the moment as I don't
have access to the board right now. Please see commit:

7fa33bdb4c44155e390c9ebbc5aa4c5cfc73f6fa
ARM: SAMSUNG: Modify board files to use new PWM platform device

--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ARM/Samsung/S3C24xx: Linux-3.11 crashes when using PWM

[Jürgen Beisert]

Hi,

yesterday I tried to make the buzzer on the Mini2440 platform work again. But
when I add one of the timer device descriptions to list of devices, the
Linux-3.11 kernel crashes. This does not happen to Linux-3.10.

What I have done:

$ make mini2440_defconfig

Change one single line:

diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c 
b/arch/arm/mach-s3c24xx/mach-mini2440.c
index a83db46..d8273da 100644
--- a/arch/arm/mach-s3c24xx/mach-mini2440.c
+++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
@@ -519,6 +519,7 @@ static struct platform_device *mini2440_devices[] 
__initdata = {
        _device_iis,
        _codec,
        _audio,
+       _device_timer[0],
 };

 static void __init mini2440_map_io(void)

$ make menuconfig

+ CONFIG_DEBUG_LL
+ CONFIG_EARLY_PRINTK

(otherwise no output on the serial line)

$ make uImage

Then booting this image on my Mini2440:

[...]
booting kernel of type uimage from /dev/ram0.kernel
   Verifying Checksum ... OK
   Image Name:   Linux-3.11.0+
   Created:      2013-09-24  19:15:10 UTC
   Image Type:  ()
   Data Size:    2551080 Bytes =  2.4 MB
   Load Address: 30008000
   Entry Point:  30008000
OK
commandline: console=ttySAC0,115200 mini2440=0tbc earlyprintk 
ip=192.168.0.241:192.168.0.10:192.168.0.1:255.255.255.0::: root=/dev/nfs 
nfsroot=/root,v3,tcp,port=2049,mountport=2049,v3,tcp noinitrd 
mtdparts=nand:512k(barebox),384k(bareboxenv),2048k(kernel),-(root)
arch_number: 1999

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.11.0+ (jb@isonoe) (gcc version 4.6.2 
(OSELAS.Toolchain-2011.11.1 linaro-4.6-2011.11) ) #1 Tue Sep 24 
21:14:53 CEST 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: MINI2440
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
CPU S3C2440A (id 0x32440001)
S3C24XX Clocks, Copyright 2004 Simtec Electronics
S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: console=ttySAC0,115200 mini2440=0tbc earlyprintk 
ip=192.168.0.241:192.168.0.10:192.168.0.1:255.255.255.0::: root=/dev/nfs 
nfsroot=/root,v3,tcp,port=2049,mountport=2049,v3,tcp noinitrd 
mtdparts=nand:512k(barebox),384k(bareboxenv),2048k(kernel),-(root)
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 59784K/65536K available (3570K kernel code, 187K rwdata, 960K rodata, 
143K init, 240K bss, 5752K reserved)
Virtual kernel memory layout:
    vector  : 0x - 0x1000   (   4 kB)
    fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
    vmalloc : 0xc480 - 0xff00   ( 936 MB)
    lowmem  : 0xc000 - 0xc400   (  64 MB)
    modules : 0xbf00 - 0xc000   (  16 MB)
      .text : 0xc0008000 - 0xc0474a44   (4531 kB)
      .init : 0xc0475000 - 0xc0498d6c   ( 144 kB)
      .data : 0xc049a000 - 0xc04c8c80   ( 188 kB)
       .bss : 0xc04c8c80 - 0xc0505050   ( 241 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:103
S3C2440: IRQ Support
irq: clearing pending status 0080
irq: clearing pending status 0002
sched_clock: 16 bits at 1012kHz, resolution 987ns, wraps every 64ms
Console: colour dummy device 80x30
Calibrating delay loop... 201.52 BogoMIPS (lpj=503808)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc0363ac8 - 0xc0363b20
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
MINI2440: Option string mini2440=0tbc
MINI2440: 't' ignored, touchscreen not compiled in
MINI2440: LCD [0:240x320] 1:800x480 2:1024x768 3:320x240
S3C2440: Initialising architecture
S3C244X: Clock Support, DVS off
Unable to handle kernel NULL pointer dereference at virtual address 0084
pgd = c0004000
[0084] *pgd=
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.0+ #1
task: c383 ti: c3832000 task.ti: c3832000
PC is at get_device_parent+0x48/0x16c
LR is at get_device_parent+0x40/0x16c
pc : []    lr : []    psr: 6053
sp : c3833d88  ip : c3857354  fp : 
r10: c047546c  r9 : c0498770  r8 : c3855f8c
r7 : c04a7c98  r6 : c04a7c90  r5 : c3857300  r4 : c3857300
r3 : c04b595c  r2 :   r1 :   r0 : c04b9a34
Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: c000717f  Table: 30004000  DAC: 0017
Process swapper (pid: 1, stack limit = 0xc38321b8)
Stack: (0xc3833d88 to 0xc3834000)
3d80:                   c385c220 c3857300  c04a7c90  c01db728
3da0: c0498770 c047546c c3833dc4 c0033be8  c3857308 c38046c0 c04b595c
3dc0:  c3857300  c3855f8c

ARM/Samsung/S3C24xx: Linux-3.11 crashes when using PWM

[Jürgen Beisert]

Hi,

yesterday I tried to make the buzzer on the Mini2440 platform work again. But
when I add one of the timer device descriptions to list of devices, the
Linux-3.11 kernel crashes. This does not happen to Linux-3.10.

What I have done:

$ make mini2440_defconfig

Change one single line:

diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c 
b/arch/arm/mach-s3c24xx/mach-mini2440.c
index a83db46..d8273da 100644
--- a/arch/arm/mach-s3c24xx/mach-mini2440.c
+++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
@@ -519,6 +519,7 @@ static struct platform_device *mini2440_devices[] 
__initdata = {
        s3c_device_iis,
        uda1340_codec,
        mini2440_audio,
+       s3c_device_timer[0],
 };

 static void __init mini2440_map_io(void)

$ make menuconfig

+ CONFIG_DEBUG_LL
+ CONFIG_EARLY_PRINTK

(otherwise no output on the serial line)

$ make uImage

Then booting this image on my Mini2440:

[...]
booting kernel of type uimage from /dev/ram0.kernel
   Verifying Checksum ... OK
   Image Name:   Linux-3.11.0+
   Created:      2013-09-24  19:15:10 UTC
   Image Type:   NULL NULL NULL (NULL)
   Data Size:    2551080 Bytes =  2.4 MB
   Load Address: 30008000
   Entry Point:  30008000
OK
commandline: console=ttySAC0,115200 mini2440=0tbc earlyprintk 
ip=192.168.0.241:192.168.0.10:192.168.0.1:255.255.255.0::: root=/dev/nfs 
nfsroot=/root,v3,tcp,port=2049,mountport=2049,v3,tcp noinitrd 
mtdparts=nand:512k(barebox),384k(bareboxenv),2048k(kernel),-(root)
arch_number: 1999

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.11.0+ (jb@isonoe) (gcc version 4.6.2 
(OSELAS.Toolchain-2011.11.1 linaro-4.6-2011.11) ) #1 Tue Sep 24 
21:14:53 CEST 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: MINI2440
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
CPU S3C2440A (id 0x32440001)
S3C24XX Clocks, Copyright 2004 Simtec Electronics
S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: console=ttySAC0,115200 mini2440=0tbc earlyprintk 
ip=192.168.0.241:192.168.0.10:192.168.0.1:255.255.255.0::: root=/dev/nfs 
nfsroot=/root,v3,tcp,port=2049,mountport=2049,v3,tcp noinitrd 
mtdparts=nand:512k(barebox),384k(bareboxenv),2048k(kernel),-(root)
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 59784K/65536K available (3570K kernel code, 187K rwdata, 960K rodata, 
143K init, 240K bss, 5752K reserved)
Virtual kernel memory layout:
    vector  : 0x - 0x1000   (   4 kB)
    fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
    vmalloc : 0xc480 - 0xff00   ( 936 MB)
    lowmem  : 0xc000 - 0xc400   (  64 MB)
    modules : 0xbf00 - 0xc000   (  16 MB)
      .text : 0xc0008000 - 0xc0474a44   (4531 kB)
      .init : 0xc0475000 - 0xc0498d6c   ( 144 kB)
      .data : 0xc049a000 - 0xc04c8c80   ( 188 kB)
       .bss : 0xc04c8c80 - 0xc0505050   ( 241 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:103
S3C2440: IRQ Support
irq: clearing pending status 0080
irq: clearing pending status 0002
sched_clock: 16 bits at 1012kHz, resolution 987ns, wraps every 64ms
Console: colour dummy device 80x30
Calibrating delay loop... 201.52 BogoMIPS (lpj=503808)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc0363ac8 - 0xc0363b20
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
MINI2440: Option string mini2440=0tbc
MINI2440: 't' ignored, touchscreen not compiled in
MINI2440: LCD [0:240x320] 1:800x480 2:1024x768 3:320x240
S3C2440: Initialising architecture
S3C244X: Clock Support, DVS off
Unable to handle kernel NULL pointer dereference at virtual address 0084
pgd = c0004000
[0084] *pgd=
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.0+ #1
task: c383 ti: c3832000 task.ti: c3832000
PC is at get_device_parent+0x48/0x16c
LR is at get_device_parent+0x40/0x16c
pc : [c01db338]    lr : [c01db330]    psr: 6053
sp : c3833d88  ip : c3857354  fp : 
r10: c047546c  r9 : c0498770  r8 : c3855f8c
r7 : c04a7c98  r6 : c04a7c90  r5 : c3857300  r4 : c3857300
r3 : c04b595c  r2 :   r1 :   r0 : c04b9a34
Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: c000717f  Table: 30004000  DAC: 0017
Process swapper (pid: 1, stack limit = 0xc38321b8)
Stack: (0xc3833d88 to 0xc3834000)
3d80:                   c385c220 c3857300  c04a7c90  c01db728
3da0: c0498770 c047546c c3833dc4 c0033be8  c3857308 c38046c0

Re: ARM/Samsung/S3C24xx: Linux-3.11 crashes when using PWM

[Sylwester Nawrocki]

Hi Jürgen,

On 25/09/13 10:29, Jürgen Beisert wrote:
 Change one single line:
 
 diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c 
 b/arch/arm/mach-s3c24xx/mach-mini2440.c
 index a83db46..d8273da 100644
 --- a/arch/arm/mach-s3c24xx/mach-mini2440.c
 +++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
 @@ -519,6 +519,7 @@ static struct platform_device *mini2440_devices[] 
 __initdata = {
 s3c_device_iis,
 uda1340_codec,
 mini2440_audio,
 +   s3c_device_timer[0],
  };

I think you need to add instead:

samsung_device_pwm,

IIRC I had this working, can't verify at the moment as I don't
have access to the board right now. Please see commit:

7fa33bdb4c44155e390c9ebbc5aa4c5cfc73f6fa
ARM: SAMSUNG: Modify board files to use new PWM platform device

--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ARM/Samsung/S3C24xx: Linux-3.11 crashes when using PWM

[Jürgen Beisert]

Hi Sylwester,

On Wednesday 25 September 2013 11:18:52 Sylwester Nawrocki wrote:
 On 25/09/13 10:29, Jürgen Beisert wrote:
  Change one single line:
 
  diff --git a/arch/arm/mach-s3c24xx/mach-mini2440.c
  b/arch/arm/mach-s3c24xx/mach-mini2440.c index a83db46..d8273da 100644
  --- a/arch/arm/mach-s3c24xx/mach-mini2440.c
  +++ b/arch/arm/mach-s3c24xx/mach-mini2440.c
  @@ -519,6 +519,7 @@ static struct platform_device *mini2440_devices[]
  __initdata = { s3c_device_iis,
  uda1340_codec,
  mini2440_audio,
  +   s3c_device_timer[0],
   };

 I think you need to add instead:

   samsung_device_pwm,

 IIRC I had this working, can't verify at the moment as I don't
 have access to the board right now. Please see commit:

 7fa33bdb4c44155e390c9ebbc5aa4c5cfc73f6fa
 ARM: SAMSUNG: Modify board files to use new PWM platform device

Seems valid for 3.12, but not for 3.11.

Regards,
Juergen

-- 
Pengutronix e.K.                              | Juergen Beisert             |
Linux Solutions for Science and Industry      | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] BFS CPU scheduler v0.442 for linux-3.11

[Con Kolivas]

This is to announce a resync and minor update of the Brain Fuck Scheduler, 
version 0.442 for the latest stable linux kernel.

The patch against linux-3.11 is available here:
http://ck.kolivas.org/patches/bfs/3.0/3.11/3.11-sched-bfs-442.patch

All patches available here:
http://ck.kolivas.org/patches

Code blog:
http://ck-hack.blogspot.com

Enjoy!
お楽しみください

-- 
-ck

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] BFS CPU scheduler v0.442 for linux-3.11

[Con Kolivas]

This is to announce a resync and minor update of the Brain Fuck Scheduler, 
version 0.442 for the latest stable linux kernel.

The patch against linux-3.11 is available here:
http://ck.kolivas.org/patches/bfs/3.0/3.11/3.11-sched-bfs-442.patch

All patches available here:
http://ck.kolivas.org/patches

Code blog:
http://ck-hack.blogspot.com

Enjoy!
お楽しみください

-- 
-ck

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Willy Tarreau]

On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
> I can only recommend for everyone to send pull requests through a gmail 
> account.

The problem I'm seeing with this method to combat abusive filtering from
e-mail providers is that we'll quickly end up needing to have one account
per provider depending on whom we want to send mail. It's not e-mail anymore
if you need to transfer them from inside the recipient's network, really...

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Linus Torvalds]

On Tue, Sep 3, 2013 at 2:46 PM, Nicholas A. Bellinger
 wrote:
>
> Ok, so another PULL request was sent out last night for the missing
> target fixes below, after putting DKIM + SPF authentication in place for
> linux-iscsi.org:
>
> [GIT PULL -v3] target fixes for v3.12-rc0 (was v3.11)
> http://marc.info/?l=linux-kernel=137818849925625=2
>
> Watching the recent git activity, I can't tell if you've (not) reached
> this point in the PULL queue yet, or if this email also landed in your
> spam folder..?
>
> Care to give me a hint if your receiving these PULL emails now, or if I
> need to continue looking at why gmail is unhappy..?

That message came through, and has the line

  Received-SPF: pass (google.com: domain of n...@linux-iscsi.org
designates 67.23.28.174 as permitted sender) client-ip=67.23.28.174;

which may or may not have been the thing that made a difference.

I'll get to the pull request itself later..

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Nicholas A. Bellinger]

On Tue, 2013-09-03 at 15:44 -0700, Linus Torvalds wrote:
> On Tue, Sep 3, 2013 at 2:46 PM, Nicholas A. Bellinger
>  wrote:
> >
> > Ok, so another PULL request was sent out last night for the missing
> > target fixes below, after putting DKIM + SPF authentication in place for
> > linux-iscsi.org:
> >
> > [GIT PULL -v3] target fixes for v3.12-rc0 (was v3.11)
> > http://marc.info/?l=linux-kernel=137818849925625=2
> >
> > Watching the recent git activity, I can't tell if you've (not) reached
> > this point in the PULL queue yet, or if this email also landed in your
> > spam folder..?
> >
> > Care to give me a hint if your receiving these PULL emails now, or if I
> > need to continue looking at why gmail is unhappy..?
> 
> That message came through, and has the line
> 
>   Received-SPF: pass (google.com: domain of n...@linux-iscsi.org
> designates 67.23.28.174 as permitted sender) client-ip=67.23.28.174;
> 
> which may or may not have been the thing that made a difference.
> 

Excellent, thanks for confirming it made it through this time.

> I'll get to the pull request itself later..
> 

, now back to the real v3.12-rc1 items.

Thanks again,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Nicholas A. Bellinger]

Hi again Linus,

On Mon, 2013-09-02 at 17:50 -0700, Nicholas A. Bellinger wrote:
> On Mon, 2013-09-02 at 15:50 -0700, Linus Torvalds wrote:
> > On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
> >  wrote:
> > >
> > > Unfortunately, this doesn't include the remaining target fixes for
> > > v3.11:
> > >
> > > Re: [GIT PULL -v2] target fixes for v3.11
> > > http://marc.info/?l=linux-kernel=137799048226191=2
> > >
> > > Is there a reason why these did not get PULLed..?
> > 
> > Very simple: I have no such email in my mailbox. I see the "target
> > updates for v3.11-rc1" email (and I pulled that), and there is nothing
> > since.
> > 
> > I don't even have that mail in my lkml archives, much less as a private 
> > email.
> > 
> > I see neither youe "-v2 PULL request" nor the "One more late v3.11
> > specific regression" one. In fact, I see no emails from you at all
> > from Aug 31.
> > 
> > It may be that gmail hates you for some reason...
> > 
> > [ time passes ]
> > 
> > Yup. It's in my spam-box, with gmail helpfully telling me:
> > 
> >Why is this message in Spam? We've found that lots of messages from
> > linux-iscsi.org are spam.  Learn more
> > 
> > so something is rotten in the state of linux-iscsi.org.
> > 
> > Recent messages from you were similarly tagged:
> > 
> >  "[GIT PULL -v2] target fixes for 3.11"
> >  "Re: LIO FC Target"
> >  "Re: [GIT PULL] target fixes for v3.11-rc7"
> > 
> > there might have been more. You might want to try to figure out why
> > gmail thinks that linux-iscsi.org is spammy.
> 
> Mmmm, that is what I was afraid of, looking into that now..
> 
> So if you would, please go ahead and pull target-pending/master ASAP for
> the fixes, and I'll send the parts that need to goto Greg-KH separately.
> 

Ok, so another PULL request was sent out last night for the missing
target fixes below, after putting DKIM + SPF authentication in place for
linux-iscsi.org:

[GIT PULL -v3] target fixes for v3.12-rc0 (was v3.11)
http://marc.info/?l=linux-kernel=137818849925625=2

Watching the recent git activity, I can't tell if you've (not) reached
this point in the PULL queue yet, or if this email also landed in your
spam folder..?

Care to give me a hint if your receiving these PULL emails now, or if I
need to continue looking at why gmail is unhappy..?

Thank you,

--nab 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Theodore Ts'o]

On Mon, Sep 02, 2013 at 07:56:13PM -0700, Nicholas A. Bellinger wrote:
> 
> Enabling DKIM now, and just waiting for the TXT records to update to
> verify.

The best way to verify is to send your test-email e-mail to GMail, and
then select "Show Original" from the per-message drop-down menu when
you view the message using GMail.  Then look for the
"Authentication-Results" mail header:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of ty...@thunk.org designates 
2600:3c02::f03c:91ff:fe96:be03 as permitted sender) smtp.mail=ty...@thunk.org;
   dkim=pass header.i=@thunk.org

This will confirm whether or not you got all of the details right.
And note that Google is IPv6-enabled, which means that if you are
using SPF, and your mail server on Rackspace also has IPv6 enabled
(which is likely), do make sure your SPF records includes both its
IPV4 and IPV6 addresses; or else you might be getting an SPF soft- or
hard- fail that could end up marking your mail as possibly being spam,
even if other mail servers which are not IPv6 enabled think it's fine.

Good luck,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Geert Uytterhoeven]

On Tue, Sep 3, 2013 at 12:50 AM, Linus Torvalds
 wrote:
>> Is there a reason why these did not get PULLed..?
>
> Very simple: I have no such email in my mailbox. I see the "target
> updates for v3.11-rc1" email (and I pulled that), and there is nothing
> since.
>
> I don't even have that mail in my lkml archives, much less as a private email.
>
> I see neither youe "-v2 PULL request" nor the "One more late v3.11
> specific regression" one. In fact, I see no emails from you at all
> from Aug 31.
>
> It may be that gmail hates you for some reason...
>
> [ time passes ]
>
> Yup. It's in my spam-box, with gmail helpfully telling me:
>
>Why is this message in Spam? We've found that lots of messages from
> linux-iscsi.org are spam.  Learn more
>
> so something is rotten in the state of linux-iscsi.org.

Funny, I did receive it without spam-label.

I do search for "label:linux-kernel in:spam" once in a while, to unspam some.
Perhaps I taught gmail Nicholas' emails are not spam for me ;-)

Note that a long time ago, I added special gmail filters to not mark emails from
some kernel-hacking Google employees as spam. Just marking them as not spam
over and over didn't help, as they were using non-google SMTP servers for
their outgoing email.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Nicholas A. Bellinger]

Hi again Linus,

On Mon, 2013-09-02 at 17:50 -0700, Nicholas A. Bellinger wrote:
 On Mon, 2013-09-02 at 15:50 -0700, Linus Torvalds wrote:
  On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
  n...@linux-iscsi.org wrote:
  
   Unfortunately, this doesn't include the remaining target fixes for
   v3.11:
  
   Re: [GIT PULL -v2] target fixes for v3.11
   http://marc.info/?l=linux-kernelm=137799048226191w=2
  
   Is there a reason why these did not get PULLed..?
  
  Very simple: I have no such email in my mailbox. I see the target
  updates for v3.11-rc1 email (and I pulled that), and there is nothing
  since.
  
  I don't even have that mail in my lkml archives, much less as a private 
  email.
  
  I see neither youe -v2 PULL request nor the One more late v3.11
  specific regression one. In fact, I see no emails from you at all
  from Aug 31.
  
  It may be that gmail hates you for some reason...
  
  [ time passes ]
  
  Yup. It's in my spam-box, with gmail helpfully telling me:
  
 Why is this message in Spam? We've found that lots of messages from
  linux-iscsi.org are spam.  Learn more
  
  so something is rotten in the state of linux-iscsi.org.
  
  Recent messages from you were similarly tagged:
  
   [GIT PULL -v2] target fixes for 3.11
   Re: LIO FC Target
   Re: [GIT PULL] target fixes for v3.11-rc7
  
  there might have been more. You might want to try to figure out why
  gmail thinks that linux-iscsi.org is spammy.
 
 Mmmm, that is what I was afraid of, looking into that now..
 
 So if you would, please go ahead and pull target-pending/master ASAP for
 the fixes, and I'll send the parts that need to goto Greg-KH separately.
 

Ok, so another PULL request was sent out last night for the missing
target fixes below, after putting DKIM + SPF authentication in place for
linux-iscsi.org:

[GIT PULL -v3] target fixes for v3.12-rc0 (was v3.11)
http://marc.info/?l=linux-kernelm=137818849925625w=2

Watching the recent git activity, I can't tell if you've (not) reached
this point in the PULL queue yet, or if this email also landed in your
spam folder..?

Care to give me a hint if your receiving these PULL emails now, or if I
need to continue looking at why gmail is unhappy..?

Thank you,

--nab 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Nicholas A. Bellinger]

On Tue, 2013-09-03 at 15:44 -0700, Linus Torvalds wrote:
 On Tue, Sep 3, 2013 at 2:46 PM, Nicholas A. Bellinger
 n...@linux-iscsi.org wrote:
 
  Ok, so another PULL request was sent out last night for the missing
  target fixes below, after putting DKIM + SPF authentication in place for
  linux-iscsi.org:
 
  [GIT PULL -v3] target fixes for v3.12-rc0 (was v3.11)
  http://marc.info/?l=linux-kernelm=137818849925625w=2
 
  Watching the recent git activity, I can't tell if you've (not) reached
  this point in the PULL queue yet, or if this email also landed in your
  spam folder..?
 
  Care to give me a hint if your receiving these PULL emails now, or if I
  need to continue looking at why gmail is unhappy..?
 
 That message came through, and has the line
 
   Received-SPF: pass (google.com: domain of n...@linux-iscsi.org
 designates 67.23.28.174 as permitted sender) client-ip=67.23.28.174;
 
 which may or may not have been the thing that made a difference.
 

Excellent, thanks for confirming it made it through this time.

 I'll get to the pull request itself later..
 

nod, now back to the real v3.12-rc1 items.

Thanks again,

--nab

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Linus Torvalds]

On Tue, Sep 3, 2013 at 2:46 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:

 Ok, so another PULL request was sent out last night for the missing
 target fixes below, after putting DKIM + SPF authentication in place for
 linux-iscsi.org:

 [GIT PULL -v3] target fixes for v3.12-rc0 (was v3.11)
 http://marc.info/?l=linux-kernelm=137818849925625w=2

 Watching the recent git activity, I can't tell if you've (not) reached
 this point in the PULL queue yet, or if this email also landed in your
 spam folder..?

 Care to give me a hint if your receiving these PULL emails now, or if I
 need to continue looking at why gmail is unhappy..?

That message came through, and has the line

  Received-SPF: pass (google.com: domain of n...@linux-iscsi.org
designates 67.23.28.174 as permitted sender) client-ip=67.23.28.174;

which may or may not have been the thing that made a difference.

I'll get to the pull request itself later..

  Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Willy Tarreau]

On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
 I can only recommend for everyone to send pull requests through a gmail 
 account.

The problem I'm seeing with this method to combat abusive filtering from
e-mail providers is that we'll quickly end up needing to have one account
per provider depending on whom we want to send mail. It's not e-mail anymore
if you need to transfer them from inside the recipient's network, really...

Willy

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Geert Uytterhoeven]

On Tue, Sep 3, 2013 at 12:50 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 Is there a reason why these did not get PULLed..?

 Very simple: I have no such email in my mailbox. I see the target
 updates for v3.11-rc1 email (and I pulled that), and there is nothing
 since.

 I don't even have that mail in my lkml archives, much less as a private email.

 I see neither youe -v2 PULL request nor the One more late v3.11
 specific regression one. In fact, I see no emails from you at all
 from Aug 31.

 It may be that gmail hates you for some reason...

 [ time passes ]

 Yup. It's in my spam-box, with gmail helpfully telling me:

Why is this message in Spam? We've found that lots of messages from
 linux-iscsi.org are spam.  Learn more

 so something is rotten in the state of linux-iscsi.org.

Funny, I did receive it without spam-label.

I do search for label:linux-kernel in:spam once in a while, to unspam some.
Perhaps I taught gmail Nicholas' emails are not spam for me ;-)

Note that a long time ago, I added special gmail filters to not mark emails from
some kernel-hacking Google employees as spam. Just marking them as not spam
over and over didn't help, as they were using non-google SMTP servers for
their outgoing email.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Theodore Ts'o]

On Mon, Sep 02, 2013 at 07:56:13PM -0700, Nicholas A. Bellinger wrote:
 
 Enabling DKIM now, and just waiting for the TXT records to update to
 verify.

The best way to verify is to send your test-email e-mail to GMail, and
then select Show Original from the per-message drop-down menu when
you view the message using GMail.  Then look for the
Authentication-Results mail header:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of ty...@thunk.org designates 
2600:3c02::f03c:91ff:fe96:be03 as permitted sender) smtp.mail=ty...@thunk.org;
   dkim=pass header.i=@thunk.org

This will confirm whether or not you got all of the details right.
And note that Google is IPv6-enabled, which means that if you are
using SPF, and your mail server on Rackspace also has IPv6 enabled
(which is likely), do make sure your SPF records includes both its
IPV4 and IPV6 addresses; or else you might be getting an SPF soft- or
hard- fail that could end up marking your mail as possibly being spam,
even if other mail servers which are not IPv6 enabled think it's fine.

Good luck,

- Ted
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Nicholas A. Bellinger]

Hi Ted,

On Mon, 2013-09-02 at 22:17 -0400, Theodore Ts'o wrote:
> On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
> > I don't think it has anything to do with linux-iscsi.org.
> > Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
> > sent through it can not be logged and examined by a certain US government 
> > agency.
> 
> Hardly.  mail.linux-iscsi.org is hosted by Rackspace, which is most
> certainly in the US.  There may be spammers using some of Rackspace
> subnets, which is much more likely to have something to be the issue.
> 
> I had a similar issue with thunk.org, which is hosted by Linode.  In
> my case, part of the problem was that I was that I moved my host to a
> different Linode datacenter (from Dallas to Atlanta), and I forgot to
> update my SPF record, so e-mails with an SMTP envelope address of
> ty...@thunk.org were getting a soft-fail.  (And e-mails with an SMTP
> return address of ty...@mit.edu but sent from imap.thunk.org were
> always getting a soft-fail, which would tend to increase the
> likelihood that if the e-mail tripped other hueristics, would cause it
> to be considered spam.)
> 
> Fixing my SPF record, and enabling DKIM (with a DKIM key published for
> thunk.org in DNS, and making sure that I always used an SMTP envelope
> return address of ty...@thunk.org, even if the RFC 822 from address
> stated ty...@mit.edu) fixed the spam false positive issues for me.
> 
> (Hint: installing and configuring OpenDKIM really isn't all that hard.
> I did it in less than an hour.)

, thanks for the additional information.

Enabling DKIM now, and just waiting for the TXT records to update to
verify.

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Theodore Ts'o]

On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
> I don't think it has anything to do with linux-iscsi.org.
> Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
> sent through it can not be logged and examined by a certain US government 
> agency.

Hardly.  mail.linux-iscsi.org is hosted by Rackspace, which is most
certainly in the US.  There may be spammers using some of Rackspace
subnets, which is much more likely to have something to be the issue.

I had a similar issue with thunk.org, which is hosted by Linode.  In
my case, part of the problem was that I was that I moved my host to a
different Linode datacenter (from Dallas to Atlanta), and I forgot to
update my SPF record, so e-mails with an SMTP envelope address of
ty...@thunk.org were getting a soft-fail.  (And e-mails with an SMTP
return address of ty...@mit.edu but sent from imap.thunk.org were
always getting a soft-fail, which would tend to increase the
likelihood that if the e-mail tripped other hueristics, would cause it
to be considered spam.)

Fixing my SPF record, and enabling DKIM (with a DKIM key published for
thunk.org in DNS, and making sure that I always used an SMTP envelope
return address of ty...@thunk.org, even if the RFC 822 from address
stated ty...@mit.edu) fixed the spam false positive issues for me.

(Hint: installing and configuring OpenDKIM really isn't all that hard.
I did it in less than an hour.)

> I had the same experience; Google blocks all e-mail from my private provider
> (located in Singapore). When asked by the provider, they claimed to know
> nothing about it. No, my provider doesn't forward more spam than other 
> providers,
> and definitely less than, say, Yahoo.

One of the things that might be happening is that your private
provider may be hosting mailing lists used by companies to send
marketing "newsletters".  Unfortunately, sometimes it's a pain to
subscribe from such newsletters, and some users will just simply hit
the "it's spam" button to make such newsletters go away.  For a small
provider, it's easier for a percentage of e-mails being emitted from a
mailer to be considered spam to exceed some magic threshold, thus
increasing the "spam score" for e-mails originating from that
provider.

I'll also note that Yahoo uses DKIM (heck, it invented DKIM) and using
DKIM is useful because if someone tries to fake spam using your
domain, if your e-mails are getting signed using DKIM, and the spam is
getting sent without being DKIM signed, many of the anti-spam
filtering services defintiely do take this into account.  Some may
even automatically decrease your spam score slightly just because you
are using DKIM, just because spammers tend not to do this, and using
DKIM to sign your e-mail headers makes it easier for spam filtering
systems to hold senders accountable for spam that they send.

  - Ted

P.S.  Although I work for Google, I don't know anything about the
low-level details of how Google's anti-SPAM systems work.  However,
for almost a decade, I was a member of MIT Network Operations, and was
one of the postmasters for mit.edu, back when aol.com was in its prime
(and we had a larger number of SMTP deliveries per day than AOL did).
So I know a thing or two about e-mail and I'd be really surprised
if anyone, particular a major mail provider such as Google, Yahoo,
Hotmail, etc, was filtering e-mail just because it came from a non-US
mail server.

The reality is that e-mail is international, and it's only the admins
of smaller mail services (perhaps desperate to filter out vast
quantities of Russian or Chinese Spam, and figuring that they weren't
expecting any valid e-mails from those countries), that would do
something as silly has filtering based on geographic source locations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Nicholas A. Bellinger]

On Mon, 2013-09-02 at 15:50 -0700, Linus Torvalds wrote:
> On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
>  wrote:
> >
> > Unfortunately, this doesn't include the remaining target fixes for
> > v3.11:
> >
> > Re: [GIT PULL -v2] target fixes for v3.11
> > http://marc.info/?l=linux-kernel=137799048226191=2
> >
> > Is there a reason why these did not get PULLed..?
> 
> Very simple: I have no such email in my mailbox. I see the "target
> updates for v3.11-rc1" email (and I pulled that), and there is nothing
> since.
> 
> I don't even have that mail in my lkml archives, much less as a private email.
> 
> I see neither youe "-v2 PULL request" nor the "One more late v3.11
> specific regression" one. In fact, I see no emails from you at all
> from Aug 31.
> 
> It may be that gmail hates you for some reason...
> 
> [ time passes ]
> 
> Yup. It's in my spam-box, with gmail helpfully telling me:
> 
>Why is this message in Spam? We've found that lots of messages from
> linux-iscsi.org are spam.  Learn more
> 
> so something is rotten in the state of linux-iscsi.org.
> 
> Recent messages from you were similarly tagged:
> 
>  "[GIT PULL -v2] target fixes for 3.11"
>  "Re: LIO FC Target"
>  "Re: [GIT PULL] target fixes for v3.11-rc7"
> 
> there might have been more. You might want to try to figure out why
> gmail thinks that linux-iscsi.org is spammy.

Mmmm, that is what I was afraid of, looking into that now..

So if you would, please go ahead and pull target-pending/master ASAP for
the fixes, and I'll send the parts that need to goto Greg-KH separately.

Thanks,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux 3.11

[Juan Barry Manuel Canham]

I noticed that linux-iscsi.org isn't doing much to protect itself from being 
used as a spam source. If you setup the following you should be less likely to 
be marked as spam:

* SPF record (setup both spf and a txt spf record for compatibility) 
* DMARC record to enforce SPF and allow servers to contact you when linux-
iscsi.org is used as a spam source
* DKIM - more work and probably not needed, but I suspect having valid dkim 
signatures will help with some mail servers spam rankings 

Apologies as this isn't really Linux kernel related stuff but it might help 
other developers avoid being spammed by gmail too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Guenter Roeck]

On 09/02/2013 03:50 PM, Linus Torvalds wrote:

On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
 wrote:


Unfortunately, this doesn't include the remaining target fixes for
v3.11:

Re: [GIT PULL -v2] target fixes for v3.11
http://marc.info/?l=linux-kernel=137799048226191=2

Is there a reason why these did not get PULLed..?


Very simple: I have no such email in my mailbox. I see the "target
updates for v3.11-rc1" email (and I pulled that), and there is nothing
since.

I don't even have that mail in my lkml archives, much less as a private email.

I see neither youe "-v2 PULL request" nor the "One more late v3.11
specific regression" one. In fact, I see no emails from you at all
from Aug 31.

It may be that gmail hates you for some reason...

[ time passes ]

Yup. It's in my spam-box, with gmail helpfully telling me:

Why is this message in Spam? We've found that lots of messages from
linux-iscsi.org are spam.  Learn more

so something is rotten in the state of linux-iscsi.org.

Recent messages from you were similarly tagged:

  "[GIT PULL -v2] target fixes for 3.11"
  "Re: LIO FC Target"
  "Re: [GIT PULL] target fixes for v3.11-rc7"

there might have been more. You might want to try to figure out why
gmail thinks that linux-iscsi.org is spammy.



I don't think it has anything to do with linux-iscsi.org.
Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
sent through it can not be logged and examined by a certain US government 
agency.

I had the same experience; Google blocks all e-mail from my private provider
(located in Singapore). When asked by the provider, they claimed to know
nothing about it. No, my provider doesn't forward more spam than other 
providers,
and definitely less than, say, Yahoo.

I can only recommend for everyone to send pull requests through a gmail account.
If you set it up correctly, you can keep using your non-gmail source address
but still send it through a Google server. Just don't use it for anything else
unless you don't mind Big Brother listening in.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Linus Torvalds]

On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
 wrote:
>
> Unfortunately, this doesn't include the remaining target fixes for
> v3.11:
>
> Re: [GIT PULL -v2] target fixes for v3.11
> http://marc.info/?l=linux-kernel=137799048226191=2
>
> Is there a reason why these did not get PULLed..?

Very simple: I have no such email in my mailbox. I see the "target
updates for v3.11-rc1" email (and I pulled that), and there is nothing
since.

I don't even have that mail in my lkml archives, much less as a private email.

I see neither youe "-v2 PULL request" nor the "One more late v3.11
specific regression" one. In fact, I see no emails from you at all
from Aug 31.

It may be that gmail hates you for some reason...

[ time passes ]

Yup. It's in my spam-box, with gmail helpfully telling me:

   Why is this message in Spam? We've found that lots of messages from
linux-iscsi.org are spam.  Learn more

so something is rotten in the state of linux-iscsi.org.

Recent messages from you were similarly tagged:

 "[GIT PULL -v2] target fixes for 3.11"
 "Re: LIO FC Target"
 "Re: [GIT PULL] target fixes for v3.11-rc7"

there might have been more. You might want to try to figure out why
gmail thinks that linux-iscsi.org is spammy.

Linus


Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Nicholas A. Bellinger]

On Mon, 2013-09-02 at 14:10 -0700, Linus Torvalds wrote:
> As some people noticed, I got distracted ("Ooh, look, a squirrel..")
> and never wrote an announcement for -rc7. My bad. But it wasn't
> actually all that interesting a release apart from the date, and it
> had a silly compile error in ohci-pci if you hadn't enabled
> CONFIG_PM_RUNTIME, so we'll just forget -rc7 ever happened, ok?
> Instead, go and get the real 3.11 release, which is out there, all
> shiny and ready to be compiled and loved.
> 
> Since rc7 (ok, I lied, it happened) there's been just small fixes.
> Most of them came in from the networking tree, but there's some all
> over: some random filesystem fixes, a couple of sound fixes, a
> /proc/timer_list fix, things like that. Nothing really stands out
> (unless you happened to use the new soft-dirty code, that had a buglet
> that could really hurt), but let's hope we don't have some silly
> configuration that doesn't even compile this time around.
> 
> Shortlog appended.
> 

Hi Linus,

Unfortunately, this doesn't include the remaining target fixes for
v3.11:

Re: [GIT PULL -v2] target fixes for v3.11
http://marc.info/?l=linux-kernel=137799048226191=2

Is there a reason why these did not get PULLed..?

Thanks,

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 3.11

[Linus Torvalds]

As some people noticed, I got distracted ("Ooh, look, a squirrel..")
and never wrote an announcement for -rc7. My bad. But it wasn't
actually all that interesting a release apart from the date, and it
had a silly compile error in ohci-pci if you hadn't enabled
CONFIG_PM_RUNTIME, so we'll just forget -rc7 ever happened, ok?
Instead, go and get the real 3.11 release, which is out there, all
shiny and ready to be compiled and loved.

Since rc7 (ok, I lied, it happened) there's been just small fixes.
Most of them came in from the networking tree, but there's some all
over: some random filesystem fixes, a couple of sound fixes, a
/proc/timer_list fix, things like that. Nothing really stands out
(unless you happened to use the new soft-dirty code, that had a buglet
that could really hurt), but let's hope we don't have some silly
configuration that doesn't even compile this time around.

Shortlog appended.

 Linus

---

Alan Stern (1):
  USB: OHCI: fix build error related to ohci_suspend/resume

Andrew Vagin (2):
  tcp: initialize rcv_tstamp for restored sockets
  tcp: don't apply tsoffset if rcv_tsecr is zero

Andrey Vagin (1):
  memcg: check that kmem_cache has memcg_params before accessing it

Andy Lutomirski (2):
  net: Check the correct namespace when spoofing pid over SCM_RIGHTS
  Rename nsproxy.pid_ns to nsproxy.pid_ns_for_children

Ariel Elior (4):
  bnx2x: vf mark stats started
  bnx2x: Fix functionality of configuring vlan list
  bnx2x: Fix VF memory leak unload
  bnx2x: Fix VF stats sync

Barry Song (2):
  irqchip: sirf: move from legacy mode to linear irqdomain
  arm: prima2: drop nr_irqs in mach as we moved to linear irqdomain

Benjamin Herrenschmidt (1):
  powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without
hypervisor

Byungho An (1):
  net: stmmac: fixed the pbl setting with DT

Chris Clark (1):
  ipv4: sendto/hdrincl: don't use destination address found in header

Cyrill Gorcunov (1):
  mm: move_ptes -- Set soft dirty bit depending on pte type

Dan Carpenter (1):
  mISDN: return -EINVAL on error in dsp_control_req()

Daniel Borkmann (1):
  net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay

Dave Kleikamp (1):
  jfs: fix readdir cookie incompatibility with NFSv4

David Jander (1):
  regmap: rbtree: Fix overlapping rbnodes.

David S. Miller (1):
  Revert "ipv6: Don't depend on per socket memory for neighbour
discovery messages"

Eliezer Tamir (1):
  net: add cpu_relax to busy poll loop

Eric Dumazet (1):
  net: revert 8728c544a9c ("net: dev_pick_tx() fix")

Erik Hugne (1):
  tipc: set sk_err correctly when connection fails

Eugene Surovegin (1):
  powerpc/hvsi: Increase handshake timeout from 200ms to 400ms.

Felix Fietkau (1):
  mac80211: add a flag to indicate CCK support for HT clients

Goldwyn Rodrigues (1):
  fs/ocfs2/super.c: Use bigger nodestr to accomodate 32-bit node numbers

Guenter Roeck (1):
  dma/Kconfig: TI_EDMA needs to be boolean

Hannes Frederic Sowa (7):
  xfrm: make local error reporting more robust
  xfrm: introduce helper for safe determination of mtu
  ipv6: wire up skb->encapsulation
  ipv6: xfrm: dereference inner ipv6 header if encapsulated
  xfrm: choose protocol family by skb protocol
  xfrm: revert ipv4 mtu determination to dst_mtu
  ipv6: set skb->protocol on tcp, raw and ip6_append_data genereated skbs

Hans Verkuil (1):
  [SCSI] pm80xx: fix Adaptec 71605H hang

Helmut Schaa (1):
  ath9k_htc: Restore skb headroom when returning skb to mac80211

Hugh Dickins (1):
  cgroup: fix rmdir EBUSY regression in 3.11

Ian Campbell (1):
  MAINTAINERS: change my DT related maintainer address

Imre Deak (1):
  drm/i915: ivb: fix edp voltage swing reg val

Jakob Bornecrantz (1):
  drm/vmwgfx: Split GMR2_REMAP commands if they are to large

Johannes Berg (1):
  mac80211: add missing channel context release

Kevin Hilman (1):
  regmap: Add another missing header for !CONFIG_REGMAP stubs

Li Hongjun (1):
  ipv4 tunnels: fix an oops when using ipip/sit with IPsec

Libo Chen (1):
  net: xilinx: fix memleak

Linus Lüssing (1):
  bridge: separate querier and query timer into IGMP/IPv4 and MLD/IPv6 ones

Linus Torvalds (2):
  Revert "fs: Allow unprivileged linkat(..., AT_EMPTY_PATH) aka flink"
  Linux 3.11

Mag (1):
  Input: xpad - add signature for Razer Onza Classic Edition

Matteo Delfino (1):
  Input: elantech - fix packet check for v3 and v4 hardware

Michal Schmidt (3):
  jme: lower NAPI weight
  netxen: lower NAPI weight
  ps3_gelic: lower NAPI weight

Mike Frysinger (1):
  Omnikey Cardman 4000: pull in ioctl.h in user header

Mischa Jonker (1):
  Input: i8042 - disable the driver on ARC platforms

Nathan Zimmer (1):
  timer_list: correct the iterator for timer_list

Paul

Linux 3.11

[Linus Torvalds]

As some people noticed, I got distracted (Ooh, look, a squirrel..)
and never wrote an announcement for -rc7. My bad. But it wasn't
actually all that interesting a release apart from the date, and it
had a silly compile error in ohci-pci if you hadn't enabled
CONFIG_PM_RUNTIME, so we'll just forget -rc7 ever happened, ok?
Instead, go and get the real 3.11 release, which is out there, all
shiny and ready to be compiled and loved.

Since rc7 (ok, I lied, it happened) there's been just small fixes.
Most of them came in from the networking tree, but there's some all
over: some random filesystem fixes, a couple of sound fixes, a
/proc/timer_list fix, things like that. Nothing really stands out
(unless you happened to use the new soft-dirty code, that had a buglet
that could really hurt), but let's hope we don't have some silly
configuration that doesn't even compile this time around.

Shortlog appended.

 Linus

---

Alan Stern (1):
  USB: OHCI: fix build error related to ohci_suspend/resume

Andrew Vagin (2):
  tcp: initialize rcv_tstamp for restored sockets
  tcp: don't apply tsoffset if rcv_tsecr is zero

Andrey Vagin (1):
  memcg: check that kmem_cache has memcg_params before accessing it

Andy Lutomirski (2):
  net: Check the correct namespace when spoofing pid over SCM_RIGHTS
  Rename nsproxy.pid_ns to nsproxy.pid_ns_for_children

Ariel Elior (4):
  bnx2x: vf mark stats started
  bnx2x: Fix functionality of configuring vlan list
  bnx2x: Fix VF memory leak unload
  bnx2x: Fix VF stats sync

Barry Song (2):
  irqchip: sirf: move from legacy mode to linear irqdomain
  arm: prima2: drop nr_irqs in mach as we moved to linear irqdomain

Benjamin Herrenschmidt (1):
  powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without
hypervisor

Byungho An (1):
  net: stmmac: fixed the pbl setting with DT

Chris Clark (1):
  ipv4: sendto/hdrincl: don't use destination address found in header

Cyrill Gorcunov (1):
  mm: move_ptes -- Set soft dirty bit depending on pte type

Dan Carpenter (1):
  mISDN: return -EINVAL on error in dsp_control_req()

Daniel Borkmann (1):
  net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay

Dave Kleikamp (1):
  jfs: fix readdir cookie incompatibility with NFSv4

David Jander (1):
  regmap: rbtree: Fix overlapping rbnodes.

David S. Miller (1):
  Revert ipv6: Don't depend on per socket memory for neighbour
discovery messages

Eliezer Tamir (1):
  net: add cpu_relax to busy poll loop

Eric Dumazet (1):
  net: revert 8728c544a9c (net: dev_pick_tx() fix)

Erik Hugne (1):
  tipc: set sk_err correctly when connection fails

Eugene Surovegin (1):
  powerpc/hvsi: Increase handshake timeout from 200ms to 400ms.

Felix Fietkau (1):
  mac80211: add a flag to indicate CCK support for HT clients

Goldwyn Rodrigues (1):
  fs/ocfs2/super.c: Use bigger nodestr to accomodate 32-bit node numbers

Guenter Roeck (1):
  dma/Kconfig: TI_EDMA needs to be boolean

Hannes Frederic Sowa (7):
  xfrm: make local error reporting more robust
  xfrm: introduce helper for safe determination of mtu
  ipv6: wire up skb-encapsulation
  ipv6: xfrm: dereference inner ipv6 header if encapsulated
  xfrm: choose protocol family by skb protocol
  xfrm: revert ipv4 mtu determination to dst_mtu
  ipv6: set skb-protocol on tcp, raw and ip6_append_data genereated skbs

Hans Verkuil (1):
  [SCSI] pm80xx: fix Adaptec 71605H hang

Helmut Schaa (1):
  ath9k_htc: Restore skb headroom when returning skb to mac80211

Hugh Dickins (1):
  cgroup: fix rmdir EBUSY regression in 3.11

Ian Campbell (1):
  MAINTAINERS: change my DT related maintainer address

Imre Deak (1):
  drm/i915: ivb: fix edp voltage swing reg val

Jakob Bornecrantz (1):
  drm/vmwgfx: Split GMR2_REMAP commands if they are to large

Johannes Berg (1):
  mac80211: add missing channel context release

Kevin Hilman (1):
  regmap: Add another missing header for !CONFIG_REGMAP stubs

Li Hongjun (1):
  ipv4 tunnels: fix an oops when using ipip/sit with IPsec

Libo Chen (1):
  net: xilinx: fix memleak

Linus Lüssing (1):
  bridge: separate querier and query timer into IGMP/IPv4 and MLD/IPv6 ones

Linus Torvalds (2):
  Revert fs: Allow unprivileged linkat(..., AT_EMPTY_PATH) aka flink
  Linux 3.11

Mag (1):
  Input: xpad - add signature for Razer Onza Classic Edition

Matteo Delfino (1):
  Input: elantech - fix packet check for v3 and v4 hardware

Michal Schmidt (3):
  jme: lower NAPI weight
  netxen: lower NAPI weight
  ps3_gelic: lower NAPI weight

Mike Frysinger (1):
  Omnikey Cardman 4000: pull in ioctl.h in user header

Mischa Jonker (1):
  Input: i8042 - disable the driver on ARC platforms

Nathan Zimmer (1):
  timer_list: correct the iterator for timer_list

Paul Mackerras (1):
  powerpc: Work around gcc

Re: Linux 3.11

[Nicholas A. Bellinger]

On Mon, 2013-09-02 at 14:10 -0700, Linus Torvalds wrote:
 As some people noticed, I got distracted (Ooh, look, a squirrel..)
 and never wrote an announcement for -rc7. My bad. But it wasn't
 actually all that interesting a release apart from the date, and it
 had a silly compile error in ohci-pci if you hadn't enabled
 CONFIG_PM_RUNTIME, so we'll just forget -rc7 ever happened, ok?
 Instead, go and get the real 3.11 release, which is out there, all
 shiny and ready to be compiled and loved.
 
 Since rc7 (ok, I lied, it happened) there's been just small fixes.
 Most of them came in from the networking tree, but there's some all
 over: some random filesystem fixes, a couple of sound fixes, a
 /proc/timer_list fix, things like that. Nothing really stands out
 (unless you happened to use the new soft-dirty code, that had a buglet
 that could really hurt), but let's hope we don't have some silly
 configuration that doesn't even compile this time around.
 
 Shortlog appended.
 

Hi Linus,

Unfortunately, this doesn't include the remaining target fixes for
v3.11:

Re: [GIT PULL -v2] target fixes for v3.11
http://marc.info/?l=linux-kernelm=137799048226191w=2

Is there a reason why these did not get PULLed..?

Thanks,

--nab

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Linus Torvalds]

On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:

 Unfortunately, this doesn't include the remaining target fixes for
 v3.11:

 Re: [GIT PULL -v2] target fixes for v3.11
 http://marc.info/?l=linux-kernelm=137799048226191w=2

 Is there a reason why these did not get PULLed..?

Very simple: I have no such email in my mailbox. I see the target
updates for v3.11-rc1 email (and I pulled that), and there is nothing
since.

I don't even have that mail in my lkml archives, much less as a private email.

I see neither youe -v2 PULL request nor the One more late v3.11
specific regression one. In fact, I see no emails from you at all
from Aug 31.

It may be that gmail hates you for some reason...

[ time passes ]

Yup. It's in my spam-box, with gmail helpfully telling me:

   Why is this message in Spam? We've found that lots of messages from
linux-iscsi.org are spam.  Learn more

so something is rotten in the state of linux-iscsi.org.

Recent messages from you were similarly tagged:

 [GIT PULL -v2] target fixes for 3.11
 Re: LIO FC Target
 Re: [GIT PULL] target fixes for v3.11-rc7

there might have been more. You might want to try to figure out why
gmail thinks that linux-iscsi.org is spammy.

Linus


Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Guenter Roeck]

On 09/02/2013 03:50 PM, Linus Torvalds wrote:

On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
n...@linux-iscsi.org wrote:


Unfortunately, this doesn't include the remaining target fixes for
v3.11:

Re: [GIT PULL -v2] target fixes for v3.11
http://marc.info/?l=linux-kernelm=137799048226191w=2

Is there a reason why these did not get PULLed..?


Very simple: I have no such email in my mailbox. I see the target
updates for v3.11-rc1 email (and I pulled that), and there is nothing
since.

I don't even have that mail in my lkml archives, much less as a private email.

I see neither youe -v2 PULL request nor the One more late v3.11
specific regression one. In fact, I see no emails from you at all
from Aug 31.

It may be that gmail hates you for some reason...

[ time passes ]

Yup. It's in my spam-box, with gmail helpfully telling me:

Why is this message in Spam? We've found that lots of messages from
linux-iscsi.org are spam.  Learn more

so something is rotten in the state of linux-iscsi.org.

Recent messages from you were similarly tagged:

  [GIT PULL -v2] target fixes for 3.11
  Re: LIO FC Target
  Re: [GIT PULL] target fixes for v3.11-rc7

there might have been more. You might want to try to figure out why
gmail thinks that linux-iscsi.org is spammy.



I don't think it has anything to do with linux-iscsi.org.
Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
sent through it can not be logged and examined by a certain US government 
agency.

I had the same experience; Google blocks all e-mail from my private provider
(located in Singapore). When asked by the provider, they claimed to know
nothing about it. No, my provider doesn't forward more spam than other 
providers,
and definitely less than, say, Yahoo.

I can only recommend for everyone to send pull requests through a gmail account.
If you set it up correctly, you can keep using your non-gmail source address
but still send it through a Google server. Just don't use it for anything else
unless you don't mind Big Brother listening in.

Guenter

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux 3.11

[Juan Barry Manuel Canham]

I noticed that linux-iscsi.org isn't doing much to protect itself from being 
used as a spam source. If you setup the following you should be less likely to 
be marked as spam:

* SPF record (setup both spf and a txt spf record for compatibility) 
* DMARC record to enforce SPF and allow servers to contact you when linux-
iscsi.org is used as a spam source
* DKIM - more work and probably not needed, but I suspect having valid dkim 
signatures will help with some mail servers spam rankings 

Apologies as this isn't really Linux kernel related stuff but it might help 
other developers avoid being spammed by gmail too.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Nicholas A. Bellinger]

On Mon, 2013-09-02 at 15:50 -0700, Linus Torvalds wrote:
 On Mon, Sep 2, 2013 at 3:30 PM, Nicholas A. Bellinger
 n...@linux-iscsi.org wrote:
 
  Unfortunately, this doesn't include the remaining target fixes for
  v3.11:
 
  Re: [GIT PULL -v2] target fixes for v3.11
  http://marc.info/?l=linux-kernelm=137799048226191w=2
 
  Is there a reason why these did not get PULLed..?
 
 Very simple: I have no such email in my mailbox. I see the target
 updates for v3.11-rc1 email (and I pulled that), and there is nothing
 since.
 
 I don't even have that mail in my lkml archives, much less as a private email.
 
 I see neither youe -v2 PULL request nor the One more late v3.11
 specific regression one. In fact, I see no emails from you at all
 from Aug 31.
 
 It may be that gmail hates you for some reason...
 
 [ time passes ]
 
 Yup. It's in my spam-box, with gmail helpfully telling me:
 
Why is this message in Spam? We've found that lots of messages from
 linux-iscsi.org are spam.  Learn more
 
 so something is rotten in the state of linux-iscsi.org.
 
 Recent messages from you were similarly tagged:
 
  [GIT PULL -v2] target fixes for 3.11
  Re: LIO FC Target
  Re: [GIT PULL] target fixes for v3.11-rc7
 
 there might have been more. You might want to try to figure out why
 gmail thinks that linux-iscsi.org is spammy.

Mmmm, that is what I was afraid of, looking into that now..

So if you would, please go ahead and pull target-pending/master ASAP for
the fixes, and I'll send the parts that need to goto Greg-KH separately.

Thanks,

--nab

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Theodore Ts'o]

On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
 I don't think it has anything to do with linux-iscsi.org.
 Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
 sent through it can not be logged and examined by a certain US government 
 agency.

Hardly.  mail.linux-iscsi.org is hosted by Rackspace, which is most
certainly in the US.  There may be spammers using some of Rackspace
subnets, which is much more likely to have something to be the issue.

I had a similar issue with thunk.org, which is hosted by Linode.  In
my case, part of the problem was that I was that I moved my host to a
different Linode datacenter (from Dallas to Atlanta), and I forgot to
update my SPF record, so e-mails with an SMTP envelope address of
ty...@thunk.org were getting a soft-fail.  (And e-mails with an SMTP
return address of ty...@mit.edu but sent from imap.thunk.org were
always getting a soft-fail, which would tend to increase the
likelihood that if the e-mail tripped other hueristics, would cause it
to be considered spam.)

Fixing my SPF record, and enabling DKIM (with a DKIM key published for
thunk.org in DNS, and making sure that I always used an SMTP envelope
return address of ty...@thunk.org, even if the RFC 822 from address
stated ty...@mit.edu) fixed the spam false positive issues for me.

(Hint: installing and configuring OpenDKIM really isn't all that hard.
I did it in less than an hour.)

 I had the same experience; Google blocks all e-mail from my private provider
 (located in Singapore). When asked by the provider, they claimed to know
 nothing about it. No, my provider doesn't forward more spam than other 
 providers,
 and definitely less than, say, Yahoo.

One of the things that might be happening is that your private
provider may be hosting mailing lists used by companies to send
marketing newsletters.  Unfortunately, sometimes it's a pain to
subscribe from such newsletters, and some users will just simply hit
the it's spam button to make such newsletters go away.  For a small
provider, it's easier for a percentage of e-mails being emitted from a
mailer to be considered spam to exceed some magic threshold, thus
increasing the spam score for e-mails originating from that
provider.

I'll also note that Yahoo uses DKIM (heck, it invented DKIM) and using
DKIM is useful because if someone tries to fake spam using your
domain, if your e-mails are getting signed using DKIM, and the spam is
getting sent without being DKIM signed, many of the anti-spam
filtering services defintiely do take this into account.  Some may
even automatically decrease your spam score slightly just because you
are using DKIM, just because spammers tend not to do this, and using
DKIM to sign your e-mail headers makes it easier for spam filtering
systems to hold senders accountable for spam that they send.

  - Ted

P.S.  Although I work for Google, I don't know anything about the
low-level details of how Google's anti-SPAM systems work.  However,
for almost a decade, I was a member of MIT Network Operations, and was
one of the postmasters for mit.edu, back when aol.com was in its prime
(and we had a larger number of SMTP deliveries per day than AOL did).
So I know a thing or two about e-mail and I'd be really surprised
if anyone, particular a major mail provider such as Google, Yahoo,
Hotmail, etc, was filtering e-mail just because it came from a non-US
mail server.

The reality is that e-mail is international, and it's only the admins
of smaller mail services (perhaps desperate to filter out vast
quantities of Russian or Chinese Spam, and figuring that they weren't
expecting any valid e-mails from those countries), that would do
something as silly has filtering based on geographic source locations.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11

[Nicholas A. Bellinger]

Hi Ted,

On Mon, 2013-09-02 at 22:17 -0400, Theodore Ts'o wrote:
 On Mon, Sep 02, 2013 at 04:46:18PM -0700, Guenter Roeck wrote:
  I don't think it has anything to do with linux-iscsi.org.
  Possibly Nicholas' e-mail provider is not hosted in the US, meaning e-mail
  sent through it can not be logged and examined by a certain US government 
  agency.
 
 Hardly.  mail.linux-iscsi.org is hosted by Rackspace, which is most
 certainly in the US.  There may be spammers using some of Rackspace
 subnets, which is much more likely to have something to be the issue.
 
 I had a similar issue with thunk.org, which is hosted by Linode.  In
 my case, part of the problem was that I was that I moved my host to a
 different Linode datacenter (from Dallas to Atlanta), and I forgot to
 update my SPF record, so e-mails with an SMTP envelope address of
 ty...@thunk.org were getting a soft-fail.  (And e-mails with an SMTP
 return address of ty...@mit.edu but sent from imap.thunk.org were
 always getting a soft-fail, which would tend to increase the
 likelihood that if the e-mail tripped other hueristics, would cause it
 to be considered spam.)
 
 Fixing my SPF record, and enabling DKIM (with a DKIM key published for
 thunk.org in DNS, and making sure that I always used an SMTP envelope
 return address of ty...@thunk.org, even if the RFC 822 from address
 stated ty...@mit.edu) fixed the spam false positive issues for me.
 
 (Hint: installing and configuring OpenDKIM really isn't all that hard.
 I did it in less than an hour.)

nod, thanks for the additional information.

Enabling DKIM now, and just waiting for the TXT records to update to
verify.

--nab

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 3.11-rc6

[Linus Torvalds]

NTAINERS

Jan Kara (2):
  jbd2: Fix use after free after error in jbd2_journal_dirty_metadata()
  jbd2: Fix oops in jbd2_journal_file_inode()

Jeff Layton (3):
  cifs: fix bad error handling in crypto code
  cifs: set sb->s_d_op before calling d_make_root()
  cifs: don't instantiate new dentries in readdir for inodes that
need to be revalidated immediately

Jeff Liu (1):
  ocfs2: fix null pointer dereference in ocfs2_dir_foreach_blk_id()

Jesper Dangaard Brouer (1):
  net_sched: restore "linklayer atm" handling

Jesse Gross (2):
  openvswitch: Fix bad merge resolution.
  openvswitch: Reset tunnel key between input and output.

Jie Liu (1):
  ocfs2: Revert 40bd62e to avoid regression in extended allocation

Johan Hovold (6):
  USB: mos7840: fix big-endian probe
  USB: usbtmc: fix big-endian probe of Rigol devices
  USB: adutux: fix big-endian device-type reporting
  USB: ti_usb_3410_5052: fix big-endian firmware handling
  USB: mos7720: fix broken control requests
  USB: keyspan: fix null-deref at disconnect and release

Johannes Berg (6):
  nl80211: fix another nl80211_fam.attrbuf race
  mac80211: don't wait for TX status forever
  mac80211: ignore HT primary channel while connected
  cfg80211: fix P2P GO interface teardown
  mac80211: continue using disabled channels while connected
  genetlink: fix family dump race

Julia Lawall (2):
  net/vmw_vsock/af_vsock.c: drop unneeded semicolon
  drivers/net/ethernet/via/via-velocity.c: update napi implementation

Lars-Peter Clausen (1):
  ASoC: dapm: Fix empty list check in dapm_new_mux()

Li Zefan (1):
  cpuset: fix the return value of cpuset_write_u64()

Linus Lüssing (2):
  bridge: don't try to update timers in case of broken MLD queries
  batman-adv: fix potential kernel paging errors for unicast transmissions

Linus Torvalds (2):
  Fix TLB gather virtual address range invalidation corner cases
  Linux 3.11-rc6

Lothar Waßmann (3):
  ASoC: sgtl5000: prevent playback to be muted when terminating
concurrent capture
  ASoC: sgtl5000: fix buggy 'Capture Attenuate Switch' control
  drivers/rtc/rtc-stmp3xxx.c: provide timeout for potentially
endless loop polling a HW bit

Maarten Lankhorst (1):
  mutex: Fix w/w mutex deadlock injection

Maksim A. Boyko (1):
  ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam C525

Manish Chopra (1):
  qlcnic: Fix diagnostic interrupt test for 83xx adapters

Matt Burtch (1):
  USB-Serial: Fix error handling of usb_wwan

Michael S. Tsirkin (1):
  macvlan: validate flags

Michal Hocko (1):
  hugetlb: fix lockdep splat caused by pmd sharing

Michal Simek (1):
  microblaze: fix clone syscall

Moshe Lazer (1):
  net/mlx5_core: Support MANAGE_PAGES and QUERY_PAGES firmware
command changes

Oleg Nesterov (1):
  sched: fix the theoretical signal_wake_up() vs schedule() race

Oliver Neukum (1):
  usb: add two quirky touchscreen

Pablo Neira Ayuso (2):
  netfilter: xt_TCPMSS: fix handling of malformed TCP header and options
  netfilter: xt_TCPOPTSTRIP: fix possible off by one access

Peter Zijlstra (1):
  sched: Ensure update_cfs_shares() is called for parents of
continuously-running tasks

Piotr Sarna (1):
  ext4: fix mount/remount error messages for incompatible mount options

Pravin B Shelar (2):
  ip_tunnel: Do not use inner ip-header-id for tunnel ip-header-id.
  openvswitch: Use correct type while allocating flex array.

Radu Caragea (1):
  x86 get_unmapped_area(): use proper mmap base for bottom-up direction

Robin Holt (1):
  MAINTAINERS: Change ownership for SGI specific modules.

Russell King (3):
  ARM: Fix the world famous typo with is_gate_vma()
  ARM: Fix !kuser helpers case
  ARM: Fix FIQ code on VIVT CPUs

Sarveshwar Bandi (1):
  be2net: Clear any capability flags that driver is not interested in.

Solomon Peachy (1):
  cw1200: Fix spurious BUG_ON() trigger when starting AP mode.

Soren Brinkmann (2):
  clk/zynq/clkc: Add dedicated spinlock for the SWDT
  clk/zynq/clkc: Add CLK_SET_RATE_PARENT flag to ethernet muxes

Sridhar Samudrala (1):
  rtnetlink: Fix inverted check in ndo_dflt_fdb_del()

Stanislaw Gruszka (2):
  iwl4965: set power mode early
  iwl4965: reset firmware after rfkill off

Stephane Grosjean (1):
  can: pcan_usb: fix wrong memcpy() bytes length

Stephen Boyd (3):
  ARM: 7810/1: perf: Fix array out of bounds access in armpmu_map_hw_event()
  PM / QoS: Fix workqueue deadlock when using
pm_qos_update_request_timeout()
  perf/arm: Fix armpmu_map_hw_event()

Stephen Hemminger (1):
  skge: fix build on 32 bit

Stephen Warren (2):
  ARM: 7807/1: kexec: validate CPU hotplug support
  ASoC: tegra: fix Tegra30 I2S capture parameter setup

Steve French (1):
  Do not attempt to do cifs operations reading symlinks with

Linux 3.11-rc6

[Linus Torvalds]

 after error in jbd2_journal_dirty_metadata()
  jbd2: Fix oops in jbd2_journal_file_inode()

Jeff Layton (3):
  cifs: fix bad error handling in crypto code
  cifs: set sb-s_d_op before calling d_make_root()
  cifs: don't instantiate new dentries in readdir for inodes that
need to be revalidated immediately

Jeff Liu (1):
  ocfs2: fix null pointer dereference in ocfs2_dir_foreach_blk_id()

Jesper Dangaard Brouer (1):
  net_sched: restore linklayer atm handling

Jesse Gross (2):
  openvswitch: Fix bad merge resolution.
  openvswitch: Reset tunnel key between input and output.

Jie Liu (1):
  ocfs2: Revert 40bd62e to avoid regression in extended allocation

Johan Hovold (6):
  USB: mos7840: fix big-endian probe
  USB: usbtmc: fix big-endian probe of Rigol devices
  USB: adutux: fix big-endian device-type reporting
  USB: ti_usb_3410_5052: fix big-endian firmware handling
  USB: mos7720: fix broken control requests
  USB: keyspan: fix null-deref at disconnect and release

Johannes Berg (6):
  nl80211: fix another nl80211_fam.attrbuf race
  mac80211: don't wait for TX status forever
  mac80211: ignore HT primary channel while connected
  cfg80211: fix P2P GO interface teardown
  mac80211: continue using disabled channels while connected
  genetlink: fix family dump race

Julia Lawall (2):
  net/vmw_vsock/af_vsock.c: drop unneeded semicolon
  drivers/net/ethernet/via/via-velocity.c: update napi implementation

Lars-Peter Clausen (1):
  ASoC: dapm: Fix empty list check in dapm_new_mux()

Li Zefan (1):
  cpuset: fix the return value of cpuset_write_u64()

Linus Lüssing (2):
  bridge: don't try to update timers in case of broken MLD queries
  batman-adv: fix potential kernel paging errors for unicast transmissions

Linus Torvalds (2):
  Fix TLB gather virtual address range invalidation corner cases
  Linux 3.11-rc6

Lothar Waßmann (3):
  ASoC: sgtl5000: prevent playback to be muted when terminating
concurrent capture
  ASoC: sgtl5000: fix buggy 'Capture Attenuate Switch' control
  drivers/rtc/rtc-stmp3xxx.c: provide timeout for potentially
endless loop polling a HW bit

Maarten Lankhorst (1):
  mutex: Fix w/w mutex deadlock injection

Maksim A. Boyko (1):
  ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam C525

Manish Chopra (1):
  qlcnic: Fix diagnostic interrupt test for 83xx adapters

Matt Burtch (1):
  USB-Serial: Fix error handling of usb_wwan

Michael S. Tsirkin (1):
  macvlan: validate flags

Michal Hocko (1):
  hugetlb: fix lockdep splat caused by pmd sharing

Michal Simek (1):
  microblaze: fix clone syscall

Moshe Lazer (1):
  net/mlx5_core: Support MANAGE_PAGES and QUERY_PAGES firmware
command changes

Oleg Nesterov (1):
  sched: fix the theoretical signal_wake_up() vs schedule() race

Oliver Neukum (1):
  usb: add two quirky touchscreen

Pablo Neira Ayuso (2):
  netfilter: xt_TCPMSS: fix handling of malformed TCP header and options
  netfilter: xt_TCPOPTSTRIP: fix possible off by one access

Peter Zijlstra (1):
  sched: Ensure update_cfs_shares() is called for parents of
continuously-running tasks

Piotr Sarna (1):
  ext4: fix mount/remount error messages for incompatible mount options

Pravin B Shelar (2):
  ip_tunnel: Do not use inner ip-header-id for tunnel ip-header-id.
  openvswitch: Use correct type while allocating flex array.

Radu Caragea (1):
  x86 get_unmapped_area(): use proper mmap base for bottom-up direction

Robin Holt (1):
  MAINTAINERS: Change ownership for SGI specific modules.

Russell King (3):
  ARM: Fix the world famous typo with is_gate_vma()
  ARM: Fix !kuser helpers case
  ARM: Fix FIQ code on VIVT CPUs

Sarveshwar Bandi (1):
  be2net: Clear any capability flags that driver is not interested in.

Solomon Peachy (1):
  cw1200: Fix spurious BUG_ON() trigger when starting AP mode.

Soren Brinkmann (2):
  clk/zynq/clkc: Add dedicated spinlock for the SWDT
  clk/zynq/clkc: Add CLK_SET_RATE_PARENT flag to ethernet muxes

Sridhar Samudrala (1):
  rtnetlink: Fix inverted check in ndo_dflt_fdb_del()

Stanislaw Gruszka (2):
  iwl4965: set power mode early
  iwl4965: reset firmware after rfkill off

Stephane Grosjean (1):
  can: pcan_usb: fix wrong memcpy() bytes length

Stephen Boyd (3):
  ARM: 7810/1: perf: Fix array out of bounds access in armpmu_map_hw_event()
  PM / QoS: Fix workqueue deadlock when using
pm_qos_update_request_timeout()
  perf/arm: Fix armpmu_map_hw_event()

Stephen Hemminger (1):
  skge: fix build on 32 bit

Stephen Warren (2):
  ARM: 7807/1: kexec: validate CPU hotplug support
  ASoC: tegra: fix Tegra30 I2S capture parameter setup

Steve French (1):
  Do not attempt to do cifs operations reading symlinks with SMB2

Sucheta Chakraborty (1):
  qlcnic: Fix beacon state return

On WfW 3.11 (was RE: Linux 3.11-rc5)

[Yuhong Bao]

> Sadly, the numerology doesn't quite work out, and while releasing the
> final 3.11 today would be a lovely coincidence (Windows 3.11 was
> released twenty years ago today), it is not to be.

Personally, I don't consider WfW 3.11 all that impressive, especially when it 
requires a 386 anyway. You can tell that I hate the MS OS/2 2.0 fiasco quite a 
lot: 
http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-px00307-and-dr.html

And I didn't mention the CMD640/RZ1000 in this blog article, where basically 
the two IDE channels was not really independent, leading to data corruption in 
multitasking OSes. Let's just say that if OS/2 2.x actually replaced 
DOS/Windows instead of turning into an entire fiasco, these hardware would not 
likely have shipped with the problems.

Yuhong Bao--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc5

[jonsm...@gmail.com]

 CONFIG_TRACING is not set
>
> Dominik Dingel (1):
>   KVM: s390: move kvm_guest_enter,exit closer to sie
>
> Egbert Eich (1):
>   drm/mgag200: Invalidate page tables when pinning a BO
>
> Eric Sandeen (1):
>   ext4: destroy ext4_es_cachep on module unload
>
> Fabio Estevam (1):
>   i2c: i2c-mxs: Use DMA mode even for small transfers
>
> Felipe Contreras (1):
>   ACPI / video: improve quirk check in acpi_video_bqc_quirk()
>
> Florian Fainelli (1):
>   MIPS: BMIPS: fix hardware interrupt routing for boot CPU != 0
>
> H.J. Lu (1):
>   x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz
>
> Hans Verkuil (2):
>   [media] ml86v7667: fix compile warning: 'ret' set but not used
>   [media] usbtv: fix dependency
>
> Hector Palacios (1):
>   video: mxsfb: fix color settings for 18bit data bus and 32bpp
>
> Heiko Carstens (4):
>   s390: add support for LZ4-compressed kernel
>   s390: add support for IBM zBC12 machine
>   s390/perf: fix compile error (undefined reference sie_exit)
>   KVM: s390: fix pfmf non-quiescing control handling
>
> J. Bruce Fields (1):
>   nfsd4: Fix MACH_CRED NULL dereference
>
> James Hogan (1):
>   usb: xhci: add missing dma-mapping.h includes
>
> Jani Nikula (1):
>   drm/i915: do not disable backlight on vgaswitcheroo switch off
>
> Jie Liu (1):
>   btrfs: fix file truncation if FALLOC_FL_KEEP_SIZE is specified
>
> Jiri Kosina (1):
>   Revert "HID: hid-logitech-dj: querying_devices was never set"
>
> Joe Perches (1):
>   MAINTAINERS: Add separate section for USB NETWORKING DRIVERS
>
> John Sheu (1):
>   [media] s5p-mfc: Fix input/output format reporting
>
> Josef Bacik (6):
>   Btrfs: do not offset physical if we're compressed
>   Btrfs: fix backref walking when we hit a compressed extent
>   Btrfs: make sure the backref walker catches all refs to our extent
>   Btrfs: allow splitting of hole em's when dropping extent cache
>   Btrfs: release both paths before logging dir/changed extents
>   Btrfs: check to see if root_list is empty before adding it to dead roots
>
> Julius Werner (1):
>   usb: core: don't try to reset_device() a port that got just disconnected
>
> Jussi Kivilinna (1):
>   ALSA: 6fire: fix DMA issues with URB transfer_buffer usage
>
> Kuninori Morimoto (2):
>   ARM: shmobile: armadillo800eva: Don't request GPIO 166 in board code
>   shdma: fixup sh_dmae_get_partial() calculation error
>
> Lai Jiangshan (1):
>   workqueue: allow work_on_cpu() to be called recursively
>
> Lars-Peter Clausen (2):
>   iio:trigger: Fix use_count race condition
>   regmap: cache: Make sure to sync the last register in a block
>
> Li Zefan (1):
>   cgroup: fix a leak when percpu_ref_init() fails
>
> Linus Torvalds (2):
>   Revert "slub: do not put a slab to cpu partial list when cpu_partial is 
> 0"
>   Linux 3.11-rc5
>
> Linus Walleij (1):
>   MAINTAINERS: delete Srinidhi from ux500
>
> Liu Bo (2):
>   Btrfs: fix a bug of snapshot-aware defrag to make it work on
> partial extents
>   Btrfs: fix extent buffer leak after backref walking
>
> Lubomir Rintel (2):
>   [media] usbtv: Fix deinterlacing
>   [media] usbtv: Throw corrupted frames away
>
> Lucas Stach (1):
>   ARM: tegra: enable ULPI phy on Colibri T20
>
> Markos Chandras (1):
>   MIPS: PNX833x: PNX8335_PCI_ETHERNET_INT depends on CONFIG_SOC_PNX8335
>
> Martin K. Petersen (1):
>   [SCSI] Don't attempt to send extended INQUIRY command if
> skip_vpd_pages is set
>
> Martin Schwidefsky (1):
>   s390/bitops: fix find_next_bit_left
>
> Mateusz Krawczuk (1):
>   regmap: Add missing header for !CONFIG_REGMAP stubs
>
> Maxime Ripard (1):
>   i2c: mv64xxx: Document the newly introduced allwinner compatible
>
> Michael Brunner (1):
>   i2c: Fix Kontron PLD prescaler calculation
>
> Michael Neuling (5):
>   powerpc: Fix hypervisor facility unavaliable vector number
>   powerpc: Rework setting up H/FSCR bit definitions
>   powerpc: Fix context switch DSCR on POWER8
>   powerpc: Save the TAR register earlier
>   powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs
>
> Michal Srb (1):
>   drm/cirrus: Invalidate page tables when pinning a BO
>
> Michel Dänzer (1):
>   drm: Don't pass negative delta to ktime_sub_ns()
>
> Mike Qiu (1):
>   powerpc/eeh: Add missing procfs entry for PowerNV
>
> Neil Horman (1):
>   x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 ch

Re: Linux 3.11-rc5

[jonsm...@gmail.com]

: fix hardware interrupt routing for boot CPU != 0

 H.J. Lu (1):
   x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

 Hans Verkuil (2):
   [media] ml86v7667: fix compile warning: 'ret' set but not used
   [media] usbtv: fix dependency

 Hector Palacios (1):
   video: mxsfb: fix color settings for 18bit data bus and 32bpp

 Heiko Carstens (4):
   s390: add support for LZ4-compressed kernel
   s390: add support for IBM zBC12 machine
   s390/perf: fix compile error (undefined reference sie_exit)
   KVM: s390: fix pfmf non-quiescing control handling

 J. Bruce Fields (1):
   nfsd4: Fix MACH_CRED NULL dereference

 James Hogan (1):
   usb: xhci: add missing dma-mapping.h includes

 Jani Nikula (1):
   drm/i915: do not disable backlight on vgaswitcheroo switch off

 Jie Liu (1):
   btrfs: fix file truncation if FALLOC_FL_KEEP_SIZE is specified

 Jiri Kosina (1):
   Revert HID: hid-logitech-dj: querying_devices was never set

 Joe Perches (1):
   MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

 John Sheu (1):
   [media] s5p-mfc: Fix input/output format reporting

 Josef Bacik (6):
   Btrfs: do not offset physical if we're compressed
   Btrfs: fix backref walking when we hit a compressed extent
   Btrfs: make sure the backref walker catches all refs to our extent
   Btrfs: allow splitting of hole em's when dropping extent cache
   Btrfs: release both paths before logging dir/changed extents
   Btrfs: check to see if root_list is empty before adding it to dead roots

 Julius Werner (1):
   usb: core: don't try to reset_device() a port that got just disconnected

 Jussi Kivilinna (1):
   ALSA: 6fire: fix DMA issues with URB transfer_buffer usage

 Kuninori Morimoto (2):
   ARM: shmobile: armadillo800eva: Don't request GPIO 166 in board code
   shdma: fixup sh_dmae_get_partial() calculation error

 Lai Jiangshan (1):
   workqueue: allow work_on_cpu() to be called recursively

 Lars-Peter Clausen (2):
   iio:trigger: Fix use_count race condition
   regmap: cache: Make sure to sync the last register in a block

 Li Zefan (1):
   cgroup: fix a leak when percpu_ref_init() fails

 Linus Torvalds (2):
   Revert slub: do not put a slab to cpu partial list when cpu_partial is 
 0
   Linux 3.11-rc5

 Linus Walleij (1):
   MAINTAINERS: delete Srinidhi from ux500

 Liu Bo (2):
   Btrfs: fix a bug of snapshot-aware defrag to make it work on
 partial extents
   Btrfs: fix extent buffer leak after backref walking

 Lubomir Rintel (2):
   [media] usbtv: Fix deinterlacing
   [media] usbtv: Throw corrupted frames away

 Lucas Stach (1):
   ARM: tegra: enable ULPI phy on Colibri T20

 Markos Chandras (1):
   MIPS: PNX833x: PNX8335_PCI_ETHERNET_INT depends on CONFIG_SOC_PNX8335

 Martin K. Petersen (1):
   [SCSI] Don't attempt to send extended INQUIRY command if
 skip_vpd_pages is set

 Martin Schwidefsky (1):
   s390/bitops: fix find_next_bit_left

 Mateusz Krawczuk (1):
   regmap: Add missing header for !CONFIG_REGMAP stubs

 Maxime Ripard (1):
   i2c: mv64xxx: Document the newly introduced allwinner compatible

 Michael Brunner (1):
   i2c: Fix Kontron PLD prescaler calculation

 Michael Neuling (5):
   powerpc: Fix hypervisor facility unavaliable vector number
   powerpc: Rework setting up H/FSCR bit definitions
   powerpc: Fix context switch DSCR on POWER8
   powerpc: Save the TAR register earlier
   powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs

 Michal Srb (1):
   drm/cirrus: Invalidate page tables when pinning a BO

 Michel Dänzer (1):
   drm: Don't pass negative delta to ktime_sub_ns()

 Mike Qiu (1):
   powerpc/eeh: Add missing procfs entry for PowerNV

 Neil Horman (1):
   x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset

 Niels de Vos (1):
   pata_imx: expose module alias for loading from device-tree

 Nishanth Menon (5):
   regulator: palmas-pmic: doc: fix typo for sleep-mode
   regulator: palmas-pmic: doc: remove ti,tstep
   ARM: dts: omap5-uevm: document regulator signals used on the actual 
 board
   ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
   ARM: dts: omap5-uevm: update optional/unused regulator configurations

 Oleg Nesterov (12):
   tracing: Turn event/id-i_private into call-event.type
   tracing: Change event_enable/disable_read() to verify i_private != NULL
   tracing: Change event_filter_read/write to verify i_private != NULL
   tracing: Change f_start() to take event_mutex and verify i_private != 
 NULL
   tracing: Introduce remove_event_file_dir()
   tracing: Change remove_event_file_dir() to clear d_subdirs-i_private
   debugfs: debugfs_remove_recursive() must not rely on 
 list_empty(d_subdirs)
   tracing: trace_remove_event_call() should fail if call/file

On WfW 3.11 (was RE: Linux 3.11-rc5)

[Yuhong Bao]

 Sadly, the numerology doesn't quite work out, and while releasing the
 final 3.11 today would be a lovely coincidence (Windows 3.11 was
 released twenty years ago today), it is not to be.

Personally, I don't consider WfW 3.11 all that impressive, especially when it 
requires a 386 anyway. You can tell that I hate the MS OS/2 2.0 fiasco quite a 
lot: 
http://yuhongbao.blogspot.ca/2012/12/about-ms-os2-20-fiasco-px00307-and-dr.html

And I didn't mention the CMD640/RZ1000 in this blog article, where basically 
the two IDE channels was not really independent, leading to data corruption in 
multitasking OSes. Let's just say that if OS/2 2.x actually replaced 
DOS/Windows instead of turning into an entire fiasco, these hardware would not 
likely have shipped with the problems.

Yuhong Bao--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 3.11-rc5

[Linus Torvalds]

 Palacios (1):
  video: mxsfb: fix color settings for 18bit data bus and 32bpp

Heiko Carstens (4):
  s390: add support for LZ4-compressed kernel
  s390: add support for IBM zBC12 machine
  s390/perf: fix compile error (undefined reference sie_exit)
  KVM: s390: fix pfmf non-quiescing control handling

J. Bruce Fields (1):
  nfsd4: Fix MACH_CRED NULL dereference

James Hogan (1):
  usb: xhci: add missing dma-mapping.h includes

Jani Nikula (1):
  drm/i915: do not disable backlight on vgaswitcheroo switch off

Jie Liu (1):
  btrfs: fix file truncation if FALLOC_FL_KEEP_SIZE is specified

Jiri Kosina (1):
  Revert "HID: hid-logitech-dj: querying_devices was never set"

Joe Perches (1):
  MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

John Sheu (1):
  [media] s5p-mfc: Fix input/output format reporting

Josef Bacik (6):
  Btrfs: do not offset physical if we're compressed
  Btrfs: fix backref walking when we hit a compressed extent
  Btrfs: make sure the backref walker catches all refs to our extent
  Btrfs: allow splitting of hole em's when dropping extent cache
  Btrfs: release both paths before logging dir/changed extents
  Btrfs: check to see if root_list is empty before adding it to dead roots

Julius Werner (1):
  usb: core: don't try to reset_device() a port that got just disconnected

Jussi Kivilinna (1):
  ALSA: 6fire: fix DMA issues with URB transfer_buffer usage

Kuninori Morimoto (2):
  ARM: shmobile: armadillo800eva: Don't request GPIO 166 in board code
  shdma: fixup sh_dmae_get_partial() calculation error

Lai Jiangshan (1):
  workqueue: allow work_on_cpu() to be called recursively

Lars-Peter Clausen (2):
  iio:trigger: Fix use_count race condition
  regmap: cache: Make sure to sync the last register in a block

Li Zefan (1):
  cgroup: fix a leak when percpu_ref_init() fails

Linus Torvalds (2):
  Revert "slub: do not put a slab to cpu partial list when cpu_partial is 0"
  Linux 3.11-rc5

Linus Walleij (1):
  MAINTAINERS: delete Srinidhi from ux500

Liu Bo (2):
  Btrfs: fix a bug of snapshot-aware defrag to make it work on
partial extents
  Btrfs: fix extent buffer leak after backref walking

Lubomir Rintel (2):
  [media] usbtv: Fix deinterlacing
  [media] usbtv: Throw corrupted frames away

Lucas Stach (1):
  ARM: tegra: enable ULPI phy on Colibri T20

Markos Chandras (1):
  MIPS: PNX833x: PNX8335_PCI_ETHERNET_INT depends on CONFIG_SOC_PNX8335

Martin K. Petersen (1):
  [SCSI] Don't attempt to send extended INQUIRY command if
skip_vpd_pages is set

Martin Schwidefsky (1):
  s390/bitops: fix find_next_bit_left

Mateusz Krawczuk (1):
  regmap: Add missing header for !CONFIG_REGMAP stubs

Maxime Ripard (1):
  i2c: mv64xxx: Document the newly introduced allwinner compatible

Michael Brunner (1):
  i2c: Fix Kontron PLD prescaler calculation

Michael Neuling (5):
  powerpc: Fix hypervisor facility unavaliable vector number
  powerpc: Rework setting up H/FSCR bit definitions
  powerpc: Fix context switch DSCR on POWER8
  powerpc: Save the TAR register earlier
  powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs

Michal Srb (1):
  drm/cirrus: Invalidate page tables when pinning a BO

Michel Dänzer (1):
  drm: Don't pass negative delta to ktime_sub_ns()

Mike Qiu (1):
  powerpc/eeh: Add missing procfs entry for PowerNV

Neil Horman (1):
  x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset

Niels de Vos (1):
  pata_imx: expose module alias for loading from device-tree

Nishanth Menon (5):
  regulator: palmas-pmic: doc: fix typo for sleep-mode
  regulator: palmas-pmic: doc: remove ti,tstep
  ARM: dts: omap5-uevm: document regulator signals used on the actual board
  ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
  ARM: dts: omap5-uevm: update optional/unused regulator configurations

Oleg Nesterov (12):
  tracing: Turn event/id->i_private into call->event.type
  tracing: Change event_enable/disable_read() to verify i_private != NULL
  tracing: Change event_filter_read/write to verify i_private != NULL
  tracing: Change f_start() to take event_mutex and verify i_private != NULL
  tracing: Introduce remove_event_file_dir()
  tracing: Change remove_event_file_dir() to clear "d_subdirs"->i_private
  debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)
  tracing: trace_remove_event_call() should fail if call/file is in use
  userns: unshare_userns() should not populate cred on failure
  Revert "ptrace: PTRACE_DETACH should do flush_ptrace_hw_breakpoint(child)"
  userns: limit the maximum depth of user_namespace->parent chain
  dlm: kill the unnecessary and wrong device_close()->recalc_sigpending()

Patil, 

Linux 3.11-rc5

[Linus Torvalds]

 Palacios (1):
  video: mxsfb: fix color settings for 18bit data bus and 32bpp

Heiko Carstens (4):
  s390: add support for LZ4-compressed kernel
  s390: add support for IBM zBC12 machine
  s390/perf: fix compile error (undefined reference sie_exit)
  KVM: s390: fix pfmf non-quiescing control handling

J. Bruce Fields (1):
  nfsd4: Fix MACH_CRED NULL dereference

James Hogan (1):
  usb: xhci: add missing dma-mapping.h includes

Jani Nikula (1):
  drm/i915: do not disable backlight on vgaswitcheroo switch off

Jie Liu (1):
  btrfs: fix file truncation if FALLOC_FL_KEEP_SIZE is specified

Jiri Kosina (1):
  Revert HID: hid-logitech-dj: querying_devices was never set

Joe Perches (1):
  MAINTAINERS: Add separate section for USB NETWORKING DRIVERS

John Sheu (1):
  [media] s5p-mfc: Fix input/output format reporting

Josef Bacik (6):
  Btrfs: do not offset physical if we're compressed
  Btrfs: fix backref walking when we hit a compressed extent
  Btrfs: make sure the backref walker catches all refs to our extent
  Btrfs: allow splitting of hole em's when dropping extent cache
  Btrfs: release both paths before logging dir/changed extents
  Btrfs: check to see if root_list is empty before adding it to dead roots

Julius Werner (1):
  usb: core: don't try to reset_device() a port that got just disconnected

Jussi Kivilinna (1):
  ALSA: 6fire: fix DMA issues with URB transfer_buffer usage

Kuninori Morimoto (2):
  ARM: shmobile: armadillo800eva: Don't request GPIO 166 in board code
  shdma: fixup sh_dmae_get_partial() calculation error

Lai Jiangshan (1):
  workqueue: allow work_on_cpu() to be called recursively

Lars-Peter Clausen (2):
  iio:trigger: Fix use_count race condition
  regmap: cache: Make sure to sync the last register in a block

Li Zefan (1):
  cgroup: fix a leak when percpu_ref_init() fails

Linus Torvalds (2):
  Revert slub: do not put a slab to cpu partial list when cpu_partial is 0
  Linux 3.11-rc5

Linus Walleij (1):
  MAINTAINERS: delete Srinidhi from ux500

Liu Bo (2):
  Btrfs: fix a bug of snapshot-aware defrag to make it work on
partial extents
  Btrfs: fix extent buffer leak after backref walking

Lubomir Rintel (2):
  [media] usbtv: Fix deinterlacing
  [media] usbtv: Throw corrupted frames away

Lucas Stach (1):
  ARM: tegra: enable ULPI phy on Colibri T20

Markos Chandras (1):
  MIPS: PNX833x: PNX8335_PCI_ETHERNET_INT depends on CONFIG_SOC_PNX8335

Martin K. Petersen (1):
  [SCSI] Don't attempt to send extended INQUIRY command if
skip_vpd_pages is set

Martin Schwidefsky (1):
  s390/bitops: fix find_next_bit_left

Mateusz Krawczuk (1):
  regmap: Add missing header for !CONFIG_REGMAP stubs

Maxime Ripard (1):
  i2c: mv64xxx: Document the newly introduced allwinner compatible

Michael Brunner (1):
  i2c: Fix Kontron PLD prescaler calculation

Michael Neuling (5):
  powerpc: Fix hypervisor facility unavaliable vector number
  powerpc: Rework setting up H/FSCR bit definitions
  powerpc: Fix context switch DSCR on POWER8
  powerpc: Save the TAR register earlier
  powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs

Michal Srb (1):
  drm/cirrus: Invalidate page tables when pinning a BO

Michel Dänzer (1):
  drm: Don't pass negative delta to ktime_sub_ns()

Mike Qiu (1):
  powerpc/eeh: Add missing procfs entry for PowerNV

Neil Horman (1):
  x86/iommu/vt-d: Expand interrupt remapping quirk to cover x58 chipset

Niels de Vos (1):
  pata_imx: expose module alias for loading from device-tree

Nishanth Menon (5):
  regulator: palmas-pmic: doc: fix typo for sleep-mode
  regulator: palmas-pmic: doc: remove ti,tstep
  ARM: dts: omap5-uevm: document regulator signals used on the actual board
  ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC
  ARM: dts: omap5-uevm: update optional/unused regulator configurations

Oleg Nesterov (12):
  tracing: Turn event/id-i_private into call-event.type
  tracing: Change event_enable/disable_read() to verify i_private != NULL
  tracing: Change event_filter_read/write to verify i_private != NULL
  tracing: Change f_start() to take event_mutex and verify i_private != NULL
  tracing: Introduce remove_event_file_dir()
  tracing: Change remove_event_file_dir() to clear d_subdirs-i_private
  debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)
  tracing: trace_remove_event_call() should fail if call/file is in use
  userns: unshare_userns(cred) should not populate cred on failure
  Revert ptrace: PTRACE_DETACH should do flush_ptrace_hw_breakpoint(child)
  userns: limit the maximum depth of user_namespace-parent chain
  dlm: kill the unnecessary and wrong device_close()-recalc_sigpending()

Patil, Rachna (1):
  iio: ti_am335x_adc: Fix wrong samples received on 1st

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/09, Frederic Weisbecker wrote:
>
> On Thu, Aug 08, 2013 at 08:15:21PM +0200, Oleg Nesterov wrote:
> > But probably we should move "attr.bp_len == HW_BREAKPOINT_LEN_1" check
> > from arch_build_bp_info() to its caller, arch_validate_hwbkpt_settings().
> >
> > Because:
> >
> > > But this bp_len
> > > should rather be used for range breakpoints on archs that support it.
> >
> > Yes, exactly, and we already have the patches for amd, so bp->len can
> > be actually != 1 but currently we can't support because it is checked
> > in arch_build_bp_info().
>
> Hmm, but how moving that to arch_validate_hwbkpt_seetings() would solve
> the issue?

Of course, this itself won't solve the issue, sorry for confusion.

I meant that arch_build_bp_info(X86_BREAKPOINT_EXECUTE) should not fail
if ->bp_len is wrong, just because (unless we add more complications) it
can't know if it is correct or not (if the hardware supports the range
EXECUTE bps).

arch_validate_hwbkpt_settings() does the additional checks anyway, and
more importantly it checks cpu_has_bpext/mask. So I think it should also
have the additional check for X86_BREAKPOINT_EXECUTE case.

> > @@ -265,15 +262,11 @@ static int arch_build_bp_info(struct per
> > break;
> > case HW_BREAKPOINT_X:
> > info->type = X86_BREAKPOINT_EXECUTE;
> > -   /*
> > -* x86 inst breakpoints need to have a specific undefined len.
> > -* But we still need to check userspace is not trying to setup
> > -* an unsupported length, to get a range breakpoint for example.
> > -*/
> > -   if (bp->attr.bp_len == sizeof(long)) {
> > -   info->len = X86_BREAKPOINT_LEN_X;
> > -   return 0;
> > -   }
> > +   /* until we change tools/perf */
> > +   if (bp->attr.bp_len == sizeof(long))
> > +   bp->attr.bp_len = HW_BREAKPOINT_LEN_1;
>
> Too bad we need to keep that compatibility around.

Yes, agreed... Do you see a better approach?

And just in case, it is not that I think that this hack is much better
than "ignore bp_len" as you suggested before. It's up to you.

> Do you think this could be
> a problem for AMD range breakpoints?

Yes, this doesn't look exactly right if ->bp_len == 8 actually tries to
denote a range. But this is the temporary hack, and at least currently
info->mask is only used if len > LEN_8, so I hope this should be fine.

> We can also fix the tools, then may be we'll be able to remove the kernel hack
> compatibility in a few years.

Or perhaps even earlier ;) And, perhaps after we change the tools we
can add pr_warn() for this case.

> Oh I need to check other archs as well.

Yes, and I'm afraid that tools/perf needs some arch-dependant define for
HW_BREAKPOINT_X's attr.bp_len. Or perhaps attr.bp_len == 0 could mean
"choose the right length" ?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Frederic Weisbecker]

On Thu, Aug 08, 2013 at 08:15:21PM +0200, Oleg Nesterov wrote:
> On 08/08, Frederic Weisbecker wrote:
> >
> > I'm all for fixing this. May be we can start by backporting a patch that
> > ignores the value of gen_len for instruction breakpoints in x86?
> 
> Or perhaps we can start with the something like below.

(commented on the diff below)

> 
> But probably we should move "attr.bp_len == HW_BREAKPOINT_LEN_1" check
> from arch_build_bp_info() to its caller, arch_validate_hwbkpt_settings().
> 
> Because:
> 
> > But this bp_len
> > should rather be used for range breakpoints on archs that support it.
> 
> Yes, exactly, and we already have the patches for amd, so bp->len can
> be actually != 1 but currently we can't support because it is checked
> in arch_build_bp_info().

Hmm, but how moving that to arch_validate_hwbkpt_seetings() would solve
the issue?

> 
> Oleg.
> 
> --- x/arch/x86/kernel/hw_breakpoint.c
> +++ x/arch/x86/kernel/hw_breakpoint.c
> @@ -208,19 +208,16 @@ int arch_bp_generic_fields(int x86_len, 
>  {
>   /* Type */
>   switch (x86_type) {
> - case X86_BREAKPOINT_EXECUTE:
> - if (x86_len != X86_BREAKPOINT_LEN_X)
> - return -EINVAL;
> -
> - *gen_type = HW_BREAKPOINT_X;
> - *gen_len = sizeof(long);
> - return 0;
>   case X86_BREAKPOINT_WRITE:
>   *gen_type = HW_BREAKPOINT_W;
>   break;
>   case X86_BREAKPOINT_RW:
>   *gen_type = HW_BREAKPOINT_W | HW_BREAKPOINT_R;
>   break;
> + case X86_BREAKPOINT_EXECUTE:
> + *gen_type = HW_BREAKPOINT_X;
> + if (x86_len == X86_BREAKPOINT_LEN_1)
> +
>   break;
>   default:
>   return -EINVAL;
>   }
> @@ -265,15 +262,11 @@ static int arch_build_bp_info(struct per
>   break;
>   case HW_BREAKPOINT_X:
>   info->type = X86_BREAKPOINT_EXECUTE;
> - /*
> -  * x86 inst breakpoints need to have a specific undefined len.
> -  * But we still need to check userspace is not trying to setup
> -  * an unsupported length, to get a range breakpoint for example.
> -  */
> - if (bp->attr.bp_len == sizeof(long)) {
> - info->len = X86_BREAKPOINT_LEN_X;
> - return 0;
> - }
> + /* until we change tools/perf */
> + if (bp->attr.bp_len == sizeof(long))
> + bp->attr.bp_len = HW_BREAKPOINT_LEN_1;

Too bad we need to keep that compatibility around. Do you think this could be
a problem for AMD range breakpoints?

We can also fix the tools, then may be we'll be able to remove the kernel hack
compatibility in a few years.

Oh I need to check other archs as well.

thanks.

> + if (bp->attr.bp_len == HW_BREAKPOINT_LEN_1)
> + break;
>   default:
>   return -EINVAL;
>   }
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Frederic Weisbecker]

On Thu, Aug 08, 2013 at 08:15:21PM +0200, Oleg Nesterov wrote:
 On 08/08, Frederic Weisbecker wrote:
 
  I'm all for fixing this. May be we can start by backporting a patch that
  ignores the value of gen_len for instruction breakpoints in x86?
 
 Or perhaps we can start with the something like below.

(commented on the diff below)

 
 But probably we should move attr.bp_len == HW_BREAKPOINT_LEN_1 check
 from arch_build_bp_info() to its caller, arch_validate_hwbkpt_settings().
 
 Because:
 
  But this bp_len
  should rather be used for range breakpoints on archs that support it.
 
 Yes, exactly, and we already have the patches for amd, so bp-len can
 be actually != 1 but currently we can't support because it is checked
 in arch_build_bp_info().

Hmm, but how moving that to arch_validate_hwbkpt_seetings() would solve
the issue?

 
 Oleg.
 
 --- x/arch/x86/kernel/hw_breakpoint.c
 +++ x/arch/x86/kernel/hw_breakpoint.c
 @@ -208,19 +208,16 @@ int arch_bp_generic_fields(int x86_len, 
  {
   /* Type */
   switch (x86_type) {
 - case X86_BREAKPOINT_EXECUTE:
 - if (x86_len != X86_BREAKPOINT_LEN_X)
 - return -EINVAL;
 -
 - *gen_type = HW_BREAKPOINT_X;
 - *gen_len = sizeof(long);
 - return 0;
   case X86_BREAKPOINT_WRITE:
   *gen_type = HW_BREAKPOINT_W;
   break;
   case X86_BREAKPOINT_RW:
   *gen_type = HW_BREAKPOINT_W | HW_BREAKPOINT_R;
   break;
 + case X86_BREAKPOINT_EXECUTE:
 + *gen_type = HW_BREAKPOINT_X;
 + if (x86_len == X86_BREAKPOINT_LEN_1)
 +
   break;
   default:
   return -EINVAL;
   }
 @@ -265,15 +262,11 @@ static int arch_build_bp_info(struct per
   break;
   case HW_BREAKPOINT_X:
   info-type = X86_BREAKPOINT_EXECUTE;
 - /*
 -  * x86 inst breakpoints need to have a specific undefined len.
 -  * But we still need to check userspace is not trying to setup
 -  * an unsupported length, to get a range breakpoint for example.
 -  */
 - if (bp-attr.bp_len == sizeof(long)) {
 - info-len = X86_BREAKPOINT_LEN_X;
 - return 0;
 - }
 + /* until we change tools/perf */
 + if (bp-attr.bp_len == sizeof(long))
 + bp-attr.bp_len = HW_BREAKPOINT_LEN_1;

Too bad we need to keep that compatibility around. Do you think this could be
a problem for AMD range breakpoints?

We can also fix the tools, then may be we'll be able to remove the kernel hack
compatibility in a few years.

Oh I need to check other archs as well.

thanks.

 + if (bp-attr.bp_len == HW_BREAKPOINT_LEN_1)
 + break;
   default:
   return -EINVAL;
   }
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/09, Frederic Weisbecker wrote:

 On Thu, Aug 08, 2013 at 08:15:21PM +0200, Oleg Nesterov wrote:
  But probably we should move attr.bp_len == HW_BREAKPOINT_LEN_1 check
  from arch_build_bp_info() to its caller, arch_validate_hwbkpt_settings().
 
  Because:
 
   But this bp_len
   should rather be used for range breakpoints on archs that support it.
 
  Yes, exactly, and we already have the patches for amd, so bp-len can
  be actually != 1 but currently we can't support because it is checked
  in arch_build_bp_info().

 Hmm, but how moving that to arch_validate_hwbkpt_seetings() would solve
 the issue?

Of course, this itself won't solve the issue, sorry for confusion.

I meant that arch_build_bp_info(X86_BREAKPOINT_EXECUTE) should not fail
if -bp_len is wrong, just because (unless we add more complications) it
can't know if it is correct or not (if the hardware supports the range
EXECUTE bps).

arch_validate_hwbkpt_settings() does the additional checks anyway, and
more importantly it checks cpu_has_bpext/mask. So I think it should also
have the additional check for X86_BREAKPOINT_EXECUTE case.

  @@ -265,15 +262,11 @@ static int arch_build_bp_info(struct per
  break;
  case HW_BREAKPOINT_X:
  info-type = X86_BREAKPOINT_EXECUTE;
  -   /*
  -* x86 inst breakpoints need to have a specific undefined len.
  -* But we still need to check userspace is not trying to setup
  -* an unsupported length, to get a range breakpoint for example.
  -*/
  -   if (bp-attr.bp_len == sizeof(long)) {
  -   info-len = X86_BREAKPOINT_LEN_X;
  -   return 0;
  -   }
  +   /* until we change tools/perf */
  +   if (bp-attr.bp_len == sizeof(long))
  +   bp-attr.bp_len = HW_BREAKPOINT_LEN_1;

 Too bad we need to keep that compatibility around.

Yes, agreed... Do you see a better approach?

And just in case, it is not that I think that this hack is much better
than ignore bp_len as you suggested before. It's up to you.

 Do you think this could be
 a problem for AMD range breakpoints?

Yes, this doesn't look exactly right if -bp_len == 8 actually tries to
denote a range. But this is the temporary hack, and at least currently
info-mask is only used if len  LEN_8, so I hope this should be fine.

 We can also fix the tools, then may be we'll be able to remove the kernel hack
 compatibility in a few years.

Or perhaps even earlier ;) And, perhaps after we change the tools we
can add pr_warn() for this case.

 Oh I need to check other archs as well.

Yes, and I'm afraid that tools/perf needs some arch-dependant define for
HW_BREAKPOINT_X's attr.bp_len. Or perhaps attr.bp_len == 0 could mean
choose the right length ?

Oleg.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/08, Frederic Weisbecker wrote:
>
> I'm all for fixing this. May be we can start by backporting a patch that
> ignores the value of gen_len for instruction breakpoints in x86?

Or perhaps we can start with the something like below.

But probably we should move "attr.bp_len == HW_BREAKPOINT_LEN_1" check
from arch_build_bp_info() to its caller, arch_validate_hwbkpt_settings().

Because:

> But this bp_len
> should rather be used for range breakpoints on archs that support it.

Yes, exactly, and we already have the patches for amd, so bp->len can
be actually != 1 but currently we can't support because it is checked
in arch_build_bp_info().

Oleg.

--- x/arch/x86/kernel/hw_breakpoint.c
+++ x/arch/x86/kernel/hw_breakpoint.c
@@ -208,19 +208,16 @@ int arch_bp_generic_fields(int x86_len, 
 {
/* Type */
switch (x86_type) {
-   case X86_BREAKPOINT_EXECUTE:
-   if (x86_len != X86_BREAKPOINT_LEN_X)
-   return -EINVAL;
-
-   *gen_type = HW_BREAKPOINT_X;
-   *gen_len = sizeof(long);
-   return 0;
case X86_BREAKPOINT_WRITE:
*gen_type = HW_BREAKPOINT_W;
break;
case X86_BREAKPOINT_RW:
*gen_type = HW_BREAKPOINT_W | HW_BREAKPOINT_R;
break;
+   case X86_BREAKPOINT_EXECUTE:
+   *gen_type = HW_BREAKPOINT_X;
+   if (x86_len == X86_BREAKPOINT_LEN_1)
+   break;
default:
return -EINVAL;
}
@@ -265,15 +262,11 @@ static int arch_build_bp_info(struct per
break;
case HW_BREAKPOINT_X:
info->type = X86_BREAKPOINT_EXECUTE;
-   /*
-* x86 inst breakpoints need to have a specific undefined len.
-* But we still need to check userspace is not trying to setup
-* an unsupported length, to get a range breakpoint for example.
-*/
-   if (bp->attr.bp_len == sizeof(long)) {
-   info->len = X86_BREAKPOINT_LEN_X;
-   return 0;
-   }
+   /* until we change tools/perf */
+   if (bp->attr.bp_len == sizeof(long))
+   bp->attr.bp_len = HW_BREAKPOINT_LEN_1;
+   if (bp->attr.bp_len == HW_BREAKPOINT_LEN_1)
+   break;
default:
return -EINVAL;
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Frederic Weisbecker]

On Thu, Aug 08, 2013 at 05:41:07PM +0200, Oleg Nesterov wrote:
> On 08/07, Linus Torvalds wrote:
> >
> > Now, I do agree that the debug registers are *much* less likely to
> > have those kinds of really subtle issues, so maybe relaxing some of
> > the tests might be reasonable. I'd be a bit nervous about it, but if
> > it's *only* the length/alignment, and Intel people can be convinced
> > that it doesn't result in any nasty undefined behavior (as long as the
> > address is in user space), maybe we could make that change just to
> > make it easier for Wine.
> 
> Oh, I do not know. And again, this way a user can't notice the problem
> if the arguments are wrong.
> 
> But personally I think it would be nice to cleanup the perf interface,
> although probably it is too later.
> 
> On x86 execute breakpoints are only a single byte, which has to be
> the first byte of the instruction. IOW the hardware requires len = 1
> in dr7 or it doesn't work (iirc).
> 
> But for some reason perf requires bp_len = sizeof(long), not 1. And
> note that it sets info->len = X86_BREAKPOINT_LEN_X. The comment says:
> 
>   x86 inst breakpoints need to have a specific undefined len
> 
> but despite its "special" name LEN_X is simply LEN_1, and other code
> relies on this fact.
> 
> Now, ptrace correctly requires DR_LEN_1. So arch_bp_generic_fields()
> translates this into "gen_len = sizeof(long)" for validation.
> 
> arch_build_bp_info() thinks that X86_BREAKPOINT_EXECUTE should have
> ->bp_len == sizeof(long), so we translate it back into LEN_1 internally.

I did this interface and I'm sorry about it.

This bp_len == sizeof(long) requirement comes from a very buggy conception
I had at the time I wrote that. I thought it would be pretty intuitive to
assume that instruction breakpoints should be the size of the instruction
itself as a generic interface for all archs. But at least x86 instructions
size aren't static. That sizeof(long) assumption just popped up from nowhere
at 5 am two years ago I guess :-(

And worse: I realized that mistake later but never moved it in the top of the
TODO-list pile because I had the feeling that nobody was using the perf 
breakpoint
interface anyway.

I'm all for fixing this. May be we can start by backporting a patch that
ignores the value of gen_len for instruction breakpoints in x86?

I don't know how other archs use it. I need to check. But this bp_len
should rather be used for range breakpoints on archs that support it. I
hope we can still reuse it if the damage of my initial misconception
isn't too widely expanded.

What do you think?

> 
> This looks confusing, imho. And imho X86_BREAKPOINT_LEN_X should die.

Yep.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Linus Torvalds]

On Thu, Aug 8, 2013 at 8:41 AM, Oleg Nesterov  wrote:
>
> On x86 execute breakpoints are only a single byte, which has to be
> the first byte of the instruction. IOW the hardware requires len = 1
> in dr7 or it doesn't work (iirc).
>
> But for some reason perf requires bp_len = sizeof(long), not 1. And
> note that it sets info->len = X86_BREAKPOINT_LEN_X. The comment says:
>
> x86 inst breakpoints need to have a specific undefined len
>
> but despite its "special" name LEN_X is simply LEN_1, and other code
> relies on this fact.
>
> Now, ptrace correctly requires DR_LEN_1. So arch_bp_generic_fields()
> translates this into "gen_len = sizeof(long)" for validation.

Yeah, that just sounds insane. I suspect it's some misguided attempt
to be compatible either with some broken old version of perf. But if
so, I agree that the compatibility code should be elsewhere, and not
in "let's turn the _correct_ length of 1 into some random crap because
we screwed up elsewhere".

>> But the kernel address checking definitely needs to stay around for
>> security reasons.
>
> Sure. And btw it doesn't look right. I sent the patch below twice (iirc),
> perhaps I should resend it again.

Your patch looks correct.

That said,

> -   return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
> +   return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);

I'd much rather make this be more clearly about overflow, and write
this as something like

last = va + len - 1;
/* Check for overflow too */
if (last < va || end >= TASK_SIZE)

because quite frankly, the "va >= TASK_SIZE" check is kind of insane.
It makes very little semantic sense. The rewritten test can be seen as
two independent tests that both make sense individually (the first
checks for overflow, the second checks that the range isn't in kernel
space).

In fact, the overflow check could/should even be done in generic code,
methinks. There's nothing architecture-specific about that.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/07, Linus Torvalds wrote:
>
> Now, I do agree that the debug registers are *much* less likely to
> have those kinds of really subtle issues, so maybe relaxing some of
> the tests might be reasonable. I'd be a bit nervous about it, but if
> it's *only* the length/alignment, and Intel people can be convinced
> that it doesn't result in any nasty undefined behavior (as long as the
> address is in user space), maybe we could make that change just to
> make it easier for Wine.

Oh, I do not know. And again, this way a user can't notice the problem
if the arguments are wrong.

But personally I think it would be nice to cleanup the perf interface,
although probably it is too later.

On x86 execute breakpoints are only a single byte, which has to be
the first byte of the instruction. IOW the hardware requires len = 1
in dr7 or it doesn't work (iirc).

But for some reason perf requires bp_len = sizeof(long), not 1. And
note that it sets info->len = X86_BREAKPOINT_LEN_X. The comment says:

x86 inst breakpoints need to have a specific undefined len

but despite its "special" name LEN_X is simply LEN_1, and other code
relies on this fact.

Now, ptrace correctly requires DR_LEN_1. So arch_bp_generic_fields()
translates this into "gen_len = sizeof(long)" for validation.

arch_build_bp_info() thinks that X86_BREAKPOINT_EXECUTE should have
->bp_len == sizeof(long), so we translate it back into LEN_1 internally.

This looks confusing, imho. And imho X86_BREAKPOINT_LEN_X should die.

> But the kernel address checking definitely needs to stay around for
> security reasons.

Sure. And btw it doesn't look right. I sent the patch below twice (iirc),
perhaps I should resend it again.

Oleg.


Date: Fri, 9 Nov 2012 19:29:43 +0100
Subject: [PATCH] arch_check_bp_in_kernelspace: fix the range check

arch_check_bp_in_kernelspace() tries to avoid the overflow and does 2
TASK_SIZE checks but it needs OR, not AND. Consider va = TASK_SIZE -1
and len = 2 case.

Note: TASK_SIZE doesn't look right at least on x86, I think it should
be replaced by TASK_SIZE_MAX.

Signed-off-by: Oleg Nesterov 

--- x/arch/arm64/kernel/hw_breakpoint.c
+++ x/arch/arm64/kernel/hw_breakpoint.c
@@ -293,7 +293,7 @@ int arch_check_bp_in_kernelspace(struct 
va = info->address;
len = get_hbp_len(info->ctrl.len);
 
-   return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+   return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
 }
 
 /*
--- x/arch/arm/kernel/hw_breakpoint.c
+++ x/arch/arm/kernel/hw_breakpoint.c
@@ -464,7 +464,7 @@ int arch_check_bp_in_kernelspace(struct 
va = info->address;
len = get_hbp_len(info->ctrl.len);
 
-   return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+   return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
 }
 
 /*
--- x/arch/sh/kernel/hw_breakpoint.c
+++ x/arch/sh/kernel/hw_breakpoint.c
@@ -132,7 +132,7 @@ int arch_check_bp_in_kernelspace(struct 
va = info->address;
len = get_hbp_len(info->len);
 
-   return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+   return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
 }
 
 int arch_bp_generic_fields(int sh_len, int sh_type,
--- x/arch/x86/kernel/hw_breakpoint.c
+++ x/arch/x86/kernel/hw_breakpoint.c
@@ -200,7 +200,7 @@ int arch_check_bp_in_kernelspace(struct 
va = info->address;
len = get_hbp_len(info->len);
 
-   return (va >= TASK_SIZE) && ((va + len - 1) >= TASK_SIZE);
+   return (va >= TASK_SIZE) || ((va + len - 1) >= TASK_SIZE);
 }
 
 int arch_bp_generic_fields(int x86_len, int x86_type,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/07, Linus Torvalds wrote:

 Now, I do agree that the debug registers are *much* less likely to
 have those kinds of really subtle issues, so maybe relaxing some of
 the tests might be reasonable. I'd be a bit nervous about it, but if
 it's *only* the length/alignment, and Intel people can be convinced
 that it doesn't result in any nasty undefined behavior (as long as the
 address is in user space), maybe we could make that change just to
 make it easier for Wine.

Oh, I do not know. And again, this way a user can't notice the problem
if the arguments are wrong.

But personally I think it would be nice to cleanup the perf interface,
although probably it is too later.

On x86 execute breakpoints are only a single byte, which has to be
the first byte of the instruction. IOW the hardware requires len = 1
in dr7 or it doesn't work (iirc).

But for some reason perf requires bp_len = sizeof(long), not 1. And
note that it sets info-len = X86_BREAKPOINT_LEN_X. The comment says:

x86 inst breakpoints need to have a specific undefined len

but despite its special name LEN_X is simply LEN_1, and other code
relies on this fact.

Now, ptrace correctly requires DR_LEN_1. So arch_bp_generic_fields()
translates this into gen_len = sizeof(long) for validation.

arch_build_bp_info() thinks that X86_BREAKPOINT_EXECUTE should have
-bp_len == sizeof(long), so we translate it back into LEN_1 internally.

This looks confusing, imho. And imho X86_BREAKPOINT_LEN_X should die.

 But the kernel address checking definitely needs to stay around for
 security reasons.

Sure. And btw it doesn't look right. I sent the patch below twice (iirc),
perhaps I should resend it again.

Oleg.


Date: Fri, 9 Nov 2012 19:29:43 +0100
Subject: [PATCH] arch_check_bp_in_kernelspace: fix the range check

arch_check_bp_in_kernelspace() tries to avoid the overflow and does 2
TASK_SIZE checks but it needs OR, not AND. Consider va = TASK_SIZE -1
and len = 2 case.

Note: TASK_SIZE doesn't look right at least on x86, I think it should
be replaced by TASK_SIZE_MAX.

Signed-off-by: Oleg Nesterov o...@redhat.com

--- x/arch/arm64/kernel/hw_breakpoint.c
+++ x/arch/arm64/kernel/hw_breakpoint.c
@@ -293,7 +293,7 @@ int arch_check_bp_in_kernelspace(struct 
va = info-address;
len = get_hbp_len(info-ctrl.len);
 
-   return (va = TASK_SIZE)  ((va + len - 1) = TASK_SIZE);
+   return (va = TASK_SIZE) || ((va + len - 1) = TASK_SIZE);
 }
 
 /*
--- x/arch/arm/kernel/hw_breakpoint.c
+++ x/arch/arm/kernel/hw_breakpoint.c
@@ -464,7 +464,7 @@ int arch_check_bp_in_kernelspace(struct 
va = info-address;
len = get_hbp_len(info-ctrl.len);
 
-   return (va = TASK_SIZE)  ((va + len - 1) = TASK_SIZE);
+   return (va = TASK_SIZE) || ((va + len - 1) = TASK_SIZE);
 }
 
 /*
--- x/arch/sh/kernel/hw_breakpoint.c
+++ x/arch/sh/kernel/hw_breakpoint.c
@@ -132,7 +132,7 @@ int arch_check_bp_in_kernelspace(struct 
va = info-address;
len = get_hbp_len(info-len);
 
-   return (va = TASK_SIZE)  ((va + len - 1) = TASK_SIZE);
+   return (va = TASK_SIZE) || ((va + len - 1) = TASK_SIZE);
 }
 
 int arch_bp_generic_fields(int sh_len, int sh_type,
--- x/arch/x86/kernel/hw_breakpoint.c
+++ x/arch/x86/kernel/hw_breakpoint.c
@@ -200,7 +200,7 @@ int arch_check_bp_in_kernelspace(struct 
va = info-address;
len = get_hbp_len(info-len);
 
-   return (va = TASK_SIZE)  ((va + len - 1) = TASK_SIZE);
+   return (va = TASK_SIZE) || ((va + len - 1) = TASK_SIZE);
 }
 
 int arch_bp_generic_fields(int x86_len, int x86_type,


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Linus Torvalds]

On Thu, Aug 8, 2013 at 8:41 AM, Oleg Nesterov o...@redhat.com wrote:

 On x86 execute breakpoints are only a single byte, which has to be
 the first byte of the instruction. IOW the hardware requires len = 1
 in dr7 or it doesn't work (iirc).

 But for some reason perf requires bp_len = sizeof(long), not 1. And
 note that it sets info-len = X86_BREAKPOINT_LEN_X. The comment says:

 x86 inst breakpoints need to have a specific undefined len

 but despite its special name LEN_X is simply LEN_1, and other code
 relies on this fact.

 Now, ptrace correctly requires DR_LEN_1. So arch_bp_generic_fields()
 translates this into gen_len = sizeof(long) for validation.

Yeah, that just sounds insane. I suspect it's some misguided attempt
to be compatible either with some broken old version of perf. But if
so, I agree that the compatibility code should be elsewhere, and not
in let's turn the _correct_ length of 1 into some random crap because
we screwed up elsewhere.

 But the kernel address checking definitely needs to stay around for
 security reasons.

 Sure. And btw it doesn't look right. I sent the patch below twice (iirc),
 perhaps I should resend it again.

Your patch looks correct.

That said,

 -   return (va = TASK_SIZE)  ((va + len - 1) = TASK_SIZE);
 +   return (va = TASK_SIZE) || ((va + len - 1) = TASK_SIZE);

I'd much rather make this be more clearly about overflow, and write
this as something like

last = va + len - 1;
/* Check for overflow too */
if (last  va || end = TASK_SIZE)

because quite frankly, the va = TASK_SIZE check is kind of insane.
It makes very little semantic sense. The rewritten test can be seen as
two independent tests that both make sense individually (the first
checks for overflow, the second checks that the range isn't in kernel
space).

In fact, the overflow check could/should even be done in generic code,
methinks. There's nothing architecture-specific about that.

   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Frederic Weisbecker]

On Thu, Aug 08, 2013 at 05:41:07PM +0200, Oleg Nesterov wrote:
 On 08/07, Linus Torvalds wrote:
 
  Now, I do agree that the debug registers are *much* less likely to
  have those kinds of really subtle issues, so maybe relaxing some of
  the tests might be reasonable. I'd be a bit nervous about it, but if
  it's *only* the length/alignment, and Intel people can be convinced
  that it doesn't result in any nasty undefined behavior (as long as the
  address is in user space), maybe we could make that change just to
  make it easier for Wine.
 
 Oh, I do not know. And again, this way a user can't notice the problem
 if the arguments are wrong.
 
 But personally I think it would be nice to cleanup the perf interface,
 although probably it is too later.
 
 On x86 execute breakpoints are only a single byte, which has to be
 the first byte of the instruction. IOW the hardware requires len = 1
 in dr7 or it doesn't work (iirc).
 
 But for some reason perf requires bp_len = sizeof(long), not 1. And
 note that it sets info-len = X86_BREAKPOINT_LEN_X. The comment says:
 
   x86 inst breakpoints need to have a specific undefined len
 
 but despite its special name LEN_X is simply LEN_1, and other code
 relies on this fact.
 
 Now, ptrace correctly requires DR_LEN_1. So arch_bp_generic_fields()
 translates this into gen_len = sizeof(long) for validation.
 
 arch_build_bp_info() thinks that X86_BREAKPOINT_EXECUTE should have
 -bp_len == sizeof(long), so we translate it back into LEN_1 internally.

I did this interface and I'm sorry about it.

This bp_len == sizeof(long) requirement comes from a very buggy conception
I had at the time I wrote that. I thought it would be pretty intuitive to
assume that instruction breakpoints should be the size of the instruction
itself as a generic interface for all archs. But at least x86 instructions
size aren't static. That sizeof(long) assumption just popped up from nowhere
at 5 am two years ago I guess :-(

And worse: I realized that mistake later but never moved it in the top of the
TODO-list pile because I had the feeling that nobody was using the perf 
breakpoint
interface anyway.

I'm all for fixing this. May be we can start by backporting a patch that
ignores the value of gen_len for instruction breakpoints in x86?

I don't know how other archs use it. I need to check. But this bp_len
should rather be used for range breakpoints on archs that support it. I
hope we can still reuse it if the damage of my initial misconception
isn't too widely expanded.

What do you think?

 
 This looks confusing, imho. And imho X86_BREAKPOINT_LEN_X should die.

Yep.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/08, Frederic Weisbecker wrote:

 I'm all for fixing this. May be we can start by backporting a patch that
 ignores the value of gen_len for instruction breakpoints in x86?

Or perhaps we can start with the something like below.

But probably we should move attr.bp_len == HW_BREAKPOINT_LEN_1 check
from arch_build_bp_info() to its caller, arch_validate_hwbkpt_settings().

Because:

 But this bp_len
 should rather be used for range breakpoints on archs that support it.

Yes, exactly, and we already have the patches for amd, so bp-len can
be actually != 1 but currently we can't support because it is checked
in arch_build_bp_info().

Oleg.

--- x/arch/x86/kernel/hw_breakpoint.c
+++ x/arch/x86/kernel/hw_breakpoint.c
@@ -208,19 +208,16 @@ int arch_bp_generic_fields(int x86_len, 
 {
/* Type */
switch (x86_type) {
-   case X86_BREAKPOINT_EXECUTE:
-   if (x86_len != X86_BREAKPOINT_LEN_X)
-   return -EINVAL;
-
-   *gen_type = HW_BREAKPOINT_X;
-   *gen_len = sizeof(long);
-   return 0;
case X86_BREAKPOINT_WRITE:
*gen_type = HW_BREAKPOINT_W;
break;
case X86_BREAKPOINT_RW:
*gen_type = HW_BREAKPOINT_W | HW_BREAKPOINT_R;
break;
+   case X86_BREAKPOINT_EXECUTE:
+   *gen_type = HW_BREAKPOINT_X;
+   if (x86_len == X86_BREAKPOINT_LEN_1)
+   break;
default:
return -EINVAL;
}
@@ -265,15 +262,11 @@ static int arch_build_bp_info(struct per
break;
case HW_BREAKPOINT_X:
info-type = X86_BREAKPOINT_EXECUTE;
-   /*
-* x86 inst breakpoints need to have a specific undefined len.
-* But we still need to check userspace is not trying to setup
-* an unsupported length, to get a range breakpoint for example.
-*/
-   if (bp-attr.bp_len == sizeof(long)) {
-   info-len = X86_BREAKPOINT_LEN_X;
-   return 0;
-   }
+   /* until we change tools/perf */
+   if (bp-attr.bp_len == sizeof(long))
+   bp-attr.bp_len = HW_BREAKPOINT_LEN_1;
+   if (bp-attr.bp_len == HW_BREAKPOINT_LEN_1)
+   break;
default:
return -EINVAL;
}

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Linus Torvalds]

On Wed, Aug 7, 2013 at 12:27 PM, Oleg Nesterov  wrote:
>
> I guess Grazvydas only meant the "unnecessary" align/len/type checks.

Yeah, some of them may be a bit questionable, but we don't necessarily
know what each microarchitecture does for unsupported ("undefined")
situations.

Intel actually has a lot of errata for their CPU's that they won't
fix, and they tend to be all about exactly the kinds of things that
the architecture manuals say "don't do this". Things like "TSS segment
crosses a page, and you take a page fault in the middle of a task
switch" etc.

Now, I do agree that the debug registers are *much* less likely to
have those kinds of really subtle issues, so maybe relaxing some of
the tests might be reasonable. I'd be a bit nervous about it, but if
it's *only* the length/alignment, and Intel people can be convinced
that it doesn't result in any nasty undefined behavior (as long as the
address is in user space), maybe we could make that change just to
make it easier for Wine.

But the kernel address checking definitely needs to stay around for
security reasons.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/07, Linus Torvalds wrote:
>
> It's a security issue: setting debug traps on kernel code/data
> addresses can not only leak information, it can cause serious trouble
> (taking a debug trap on the first instruction of an NMI handler etc)
> including kernel stack corruption...

I guess Grazvydas only meant the "unnecessary" align/len/type checks.

But you are right of course.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Linus Torvalds]

On Wed, Aug 7, 2013 at 5:05 AM, Grazvydas Ignotas  wrote:
>
> Personally I'd say the kernel should not limit what's written to debug
> registers. Why can't I write insane values to registers in _my_
> hardware? It's not like it's going to break the hardware or anything.

It may be your hardware, but do you know what might be running on it?
It's a security issue: setting debug traps on kernel code/data
addresses can not only leak information, it can cause serious trouble
(taking a debug trap on the first instruction of an NMI handler etc)
including kernel stack corruption...

You do want the kernel to give you file permission checking even
though it's "your machine", don't you? Very similar thing.

The fact that windows allows it is kind of irrelevant. They aren't
exactly known for caring deeply.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/07, Grazvydas Ignotas wrote:
>
> It's not that wine needs all this, it's the Windows games that use
> debug registers to store random values to them for their copy
> protection stuff.

Thanks.

> My wine commits try to sidestep these
> kernel restrictions/sanity checking.

My point was, it seems that starting from 3.11 you can remove both
extra PTRACE_POKEUSER's. Unless, of course, the initial state of dr7
doesn't match dr0 - dr6 set_thread_context() is going to update.

Anyway I agree this interface is very confusing and inconvenient.

And just in case, it is not that I think set_thread_context() should
be changed, I am just wondering whether the kernel still has the bugs
which should be fixed.

> Personally I'd say the kernel should not limit what's written to debug
> registers. Why can't I write insane values to registers in _my_
> hardware? It's not like it's going to break the hardware or anything.

Even if this is safe (and btw I have no idea if this is always true or
not ;), how a user can notice the error then?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Grazvydas Ignotas]

On Tue, Aug 6, 2013 at 6:43 PM, Oleg Nesterov  wrote:
> Felipe, thanks a lot. Yes fab840f is wrong, this "bug" is already
> used as a feature.
>
> Grazvydas, I cc'ed you because I do not really understand
> set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
> with the "Linux 2.6.33+ needs ..." comment. It would be nice if you
> can check if 3.11 still needs this, in this case we probably need
> some more minor fixes in this area.
>
> In fact the first comment doesn't look right, when I look at 2.6.33
> it seems that POKEUSER(DR0-DR6) should be fine without POKEUSER(DR7),
> but this doesn't really matter and I can be easily wrong. Anyway
> this looks like a workaround to hide kernel bugs, I will appreciate
> it if you can tell if wine still needs it or not.

It's not that wine needs all this, it's the Windows games that use
debug registers to store random values to them for their copy
protection stuff. Older Linux kernels used to not care, but newer ones
started validating what's written to debug registers, and those games
started to break under wine. My wine commits try to sidestep these
kernel restrictions/sanity checking.

Personally I'd say the kernel should not limit what's written to debug
registers. Why can't I write insane values to registers in _my_
hardware? It's not like it's going to break the hardware or anything.

-- 
Gražvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Grazvydas Ignotas]

On Tue, Aug 6, 2013 at 6:43 PM, Oleg Nesterov o...@redhat.com wrote:
 Felipe, thanks a lot. Yes fab840f is wrong, this bug is already
 used as a feature.

 Grazvydas, I cc'ed you because I do not really understand
 set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
 with the Linux 2.6.33+ needs ... comment. It would be nice if you
 can check if 3.11 still needs this, in this case we probably need
 some more minor fixes in this area.

 In fact the first comment doesn't look right, when I look at 2.6.33
 it seems that POKEUSER(DR0-DR6) should be fine without POKEUSER(DR7),
 but this doesn't really matter and I can be easily wrong. Anyway
 this looks like a workaround to hide kernel bugs, I will appreciate
 it if you can tell if wine still needs it or not.

It's not that wine needs all this, it's the Windows games that use
debug registers to store random values to them for their copy
protection stuff. Older Linux kernels used to not care, but newer ones
started validating what's written to debug registers, and those games
started to break under wine. My wine commits try to sidestep these
kernel restrictions/sanity checking.

Personally I'd say the kernel should not limit what's written to debug
registers. Why can't I write insane values to registers in _my_
hardware? It's not like it's going to break the hardware or anything.

-- 
Gražvydas
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/07, Grazvydas Ignotas wrote:

 It's not that wine needs all this, it's the Windows games that use
 debug registers to store random values to them for their copy
 protection stuff.

Thanks.

 My wine commits try to sidestep these
 kernel restrictions/sanity checking.

My point was, it seems that starting from 3.11 you can remove both
extra PTRACE_POKEUSER's. Unless, of course, the initial state of dr7
doesn't match dr0 - dr6 set_thread_context() is going to update.

Anyway I agree this interface is very confusing and inconvenient.

And just in case, it is not that I think set_thread_context() should
be changed, I am just wondering whether the kernel still has the bugs
which should be fixed.

 Personally I'd say the kernel should not limit what's written to debug
 registers. Why can't I write insane values to registers in _my_
 hardware? It's not like it's going to break the hardware or anything.

Even if this is safe (and btw I have no idea if this is always true or
not ;), how a user can notice the error then?

Oleg.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Linus Torvalds]

On Wed, Aug 7, 2013 at 5:05 AM, Grazvydas Ignotas nota...@gmail.com wrote:

 Personally I'd say the kernel should not limit what's written to debug
 registers. Why can't I write insane values to registers in _my_
 hardware? It's not like it's going to break the hardware or anything.

It may be your hardware, but do you know what might be running on it?
It's a security issue: setting debug traps on kernel code/data
addresses can not only leak information, it can cause serious trouble
(taking a debug trap on the first instruction of an NMI handler etc)
including kernel stack corruption...

You do want the kernel to give you file permission checking even
though it's your machine, don't you? Very similar thing.

The fact that windows allows it is kind of irrelevant. They aren't
exactly known for caring deeply.

   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

On 08/07, Linus Torvalds wrote:

 It's a security issue: setting debug traps on kernel code/data
 addresses can not only leak information, it can cause serious trouble
 (taking a debug trap on the first instruction of an NMI handler etc)
 including kernel stack corruption...

I guess Grazvydas only meant the unnecessary align/len/type checks.

But you are right of course.

Oleg.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1] (Was: Linux 3.11-rc4)

[Linus Torvalds]

On Wed, Aug 7, 2013 at 12:27 PM, Oleg Nesterov o...@redhat.com wrote:

 I guess Grazvydas only meant the unnecessary align/len/type checks.

Yeah, some of them may be a bit questionable, but we don't necessarily
know what each microarchitecture does for unsupported (undefined)
situations.

Intel actually has a lot of errata for their CPU's that they won't
fix, and they tend to be all about exactly the kinds of things that
the architecture manuals say don't do this. Things like TSS segment
crosses a page, and you take a page fault in the middle of a task
switch etc.

Now, I do agree that the debug registers are *much* less likely to
have those kinds of really subtle issues, so maybe relaxing some of
the tests might be reasonable. I'd be a bit nervous about it, but if
it's *only* the length/alignment, and Intel people can be convinced
that it doesn't result in any nasty undefined behavior (as long as the
address is in user space), maybe we could make that change just to
make it easier for Wine.

But the kernel address checking definitely needs to stay around for
security reasons.

Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

Felipe, thanks a lot. Yes fab840f is wrong, this "bug" is already
used as a feature.

Grazvydas, I cc'ed you because I do not really understand
set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
with the "Linux 2.6.33+ needs ..." comment. It would be nice if you
can check if 3.11 still needs this, in this case we probably need
some more minor fixes in this area.

In fact the first comment doesn't look right, when I look at 2.6.33
it seems that POKEUSER(DR0-DR6) should be fine without POKEUSER(DR7),
but this doesn't really matter and I can be easily wrong. Anyway
this looks like a workaround to hide kernel bugs, I will appreciate
it if you can tell if wine still needs it or not.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/1] (Was: Linux 3.11-rc4)

[Oleg Nesterov]

Felipe, thanks a lot. Yes fab840f is wrong, this bug is already
used as a feature.

Grazvydas, I cc'ed you because I do not really understand
set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
with the Linux 2.6.33+ needs ... comment. It would be nice if you
can check if 3.11 still needs this, in this case we probably need
some more minor fixes in this area.

In fact the first comment doesn't look right, when I look at 2.6.33
it seems that POKEUSER(DR0-DR6) should be fine without POKEUSER(DR7),
but this doesn't really matter and I can be easily wrong. Anyway
this looks like a workaround to hide kernel bugs, I will appreciate
it if you can tell if wine still needs it or not.

Oleg.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Linus Torvalds]

On Mon, Aug 5, 2013 at 11:57 AM, Oleg Nesterov  wrote:
>
> Yes, yes, sure. I'll write the changelog and send git-revert tomorrow,

Thanks.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Oleg Nesterov]

On 08/05, Linus Torvalds wrote:
>
> On Mon, Aug 5, 2013 at 11:46 AM, Oleg Nesterov  wrote:
> >
> > Heh. I pulled wine-git.
> >
> > set_thread_context() does a lot of PTRACE_POKEUSER requests and then
> > it calls resume_after_ptrace() which simply does PTRACE_DETACH.
> >
> > I'll recheck tomorrow, but it really looks as if it _wants_ to leak
> > the debug registers after detach. And more, it does PTRACE_ATTACH
> > only to set these regs.
> >
> > And this is exactly what fab840f tries to prevent.
>
> Ok, so I guess it's effectively the ABI, and we should just make the
> rule be that "if you don't want stale breakpoints, then remove the
> breakpoints when you detach".

I'm afraid yes.

> And thus reverting it the right thing to do. Agreed?

Yes, yes, sure. I'll write the changelog and send git-revert tomorrow,
unless you do it yourself.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Linus Torvalds]

On Mon, Aug 5, 2013 at 11:46 AM, Oleg Nesterov  wrote:
>
> Heh. I pulled wine-git.
>
> set_thread_context() does a lot of PTRACE_POKEUSER requests and then
> it calls resume_after_ptrace() which simply does PTRACE_DETACH.
>
> I'll recheck tomorrow, but it really looks as if it _wants_ to leak
> the debug registers after detach. And more, it does PTRACE_ATTACH
> only to set these regs.
>
> And this is exactly what fab840f tries to prevent.

Ok, so I guess it's effectively the ABI, and we should just make the
rule be that "if you don't want stale breakpoints, then remove the
breakpoints when you detach".

And thus reverting it the right thing to do. Agreed?

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Oleg Nesterov]

On 08/04, Felipe Contreras wrote:
>
> I found a regression while running all v3.11-rcX kernels; Starcract II
> through wine crashes. The culprit is fab840f (ptrace: PTRACE_DETACH
> should do flush_ptrace_hw_breakpoint(child)), I revert that commit and
> there's no crash.

Heh. I pulled wine-git.

set_thread_context() does a lot of PTRACE_POKEUSER requests and then
it calls resume_after_ptrace() which simply does PTRACE_DETACH.

I'll recheck tomorrow, but it really looks as if it _wants_ to leak
the debug registers after detach. And more, it does PTRACE_ATTACH
only to set these regs.

And this is exactly what fab840f tries to prevent.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Felipe Contreras]

On Mon, Aug 5, 2013 at 12:43 PM, Felipe Contreras
 wrote:
> On Mon, Aug 5, 2013 at 12:39 PM, Linus Torvalds
>  wrote:
>
>> That said, Felipe, can you double-check that it's not timing-related
>> in some subtle way, and test multiple times with just that commit
>> reverted (and not reverted) to make sure that it's 100% that one
>> single line by that particular commit? Because it does seem very
>> benign..
>
> I tested perhaps dozens of times with the patch, and every one of them
> failed. I tested at least 6 times with the patch reverted, every one
> of them worked.
>
> I'm fairly certain that it's 100% reproducible, so it doesn't seem to be a 
> race.
>
> But I'll double-check.

Yeah, I just tested 5 times; with the patch all 5 times failed,
without the patch all 5 times worked.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Oleg Nesterov]

On 08/05, Felipe Contreras wrote:
>
> Would it be possible to just revert that patch for v3.11, and fix it later?

Sure, but it would be nice to investigate.

I think we have the time for revert, this patch was added after 3.10
so I hope we can always revert it before 3.11.

Felipe, I'll try to make a stupid debugging patch tomorrow, perhaps
you can test it...

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Oleg Nesterov]

On 08/05, Linus Torvalds wrote:
>
> On Mon, Aug 5, 2013 at 6:29 AM, Oleg Nesterov  wrote:
> >
> > I never used wine, but I am puzzled anyway. This patch really looks
> > like a simple and minor bugfix.
>
> The patch is indeed trivial, but.. What's the locking here?
>
> Afaik, ptrace_detach() by the parent can race with do_exit() by the
> child, and they now _both_ do flush_ptrace_hw_breakpoint().

That would be bad. And that is why exit_ptrace() doesn't do this.

But we rely on ptrace_freeze_traced(). If the child can exit (or
even run), we have other problems which were hopefully fixed by
9899d11f "ensure arch_ptrace/ptrace_request can never race with
SIGKILL"

> We have that whole "get tasklist_lock for writing and then
> check child->ptrace" logic there exactly due to that race, no?

Exactly. But note that this code is very old. We can remove the
"This child can be already killed" logic, and we can do more
simplifications in ptrace paths.

In fact, some recent changes already rely on the fact the tracee
can't go away, say ptrace_peek_siginfo()->spin_lock_irq(siglock)
is not safe without ptrace_freeze_traced().

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Felipe Contreras]

On Mon, Aug 5, 2013 at 12:39 PM, Linus Torvalds
 wrote:

> That said, Felipe, can you double-check that it's not timing-related
> in some subtle way, and test multiple times with just that commit
> reverted (and not reverted) to make sure that it's 100% that one
> single line by that particular commit? Because it does seem very
> benign..

I tested perhaps dozens of times with the patch, and every one of them
failed. I tested at least 6 times with the patch reverted, every one
of them worked.

I'm fairly certain that it's 100% reproducible, so it doesn't seem to be a race.

But I'll double-check.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Felipe Contreras]

On Mon, Aug 5, 2013 at 12:11 PM, Oleg Nesterov  wrote:
> On 08/05, Felipe Contreras wrote:
>>
>> On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov  wrote:
>> >
>> > Hmm. It should not crash under strace... please see below.
>> >
>> >> 953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not 
>> >> permitted)
>> >
>> > OK, so it actually uses ptrace ;)
>> >
>> > PTRACE_ATTACH fails because this child is already traced by strace, I 
>> > guess.
>> >
>> > So does Starcraft crash this way? Or does it fail in some other way?
>>
>> It's crashing just the same.
>
> But then it is not clear how fab840f can make any difference.

Yeah, it's very strange.

> wine can not use ptrace when it runs after "strace -f". But, to remind,
> I know nothing about wine. Perhaps wine uses some daemons which actually
> run/ptrace the workload?

There's this thing called wineserver, I'm not exactly sure how it would affect.

But I found this:

http://askubuntu.com/questions/146160/what-is-the-ptrace-scope-workaround-for-wine-programs-and-are-there-any-risks

Would it be possible to just revert that patch for v3.11, and fix it later?

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Linus Torvalds]

On Mon, Aug 5, 2013 at 6:29 AM, Oleg Nesterov  wrote:
>
> I never used wine, but I am puzzled anyway. This patch really looks
> like a simple and minor bugfix.

The patch is indeed trivial, but.. What's the locking here?

Afaik, ptrace_detach() by the parent can race with do_exit() by the
child, and they now _both_ do flush_ptrace_hw_breakpoint(). Or am I
wrong? We have that whole "get tasklist_lock for writing and then
check child->ptrace" logic there exactly due to that race, no?

That said, Felipe, can you double-check that it's not timing-related
in some subtle way, and test multiple times with just that commit
reverted (and not reverted) to make sure that it's 100% that one
single line by that particular commit? Because it does seem very
benign..

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_TMPFILE fs corruption (Re: Linux 3.11-rc4)

[Jörn Engel]

On Mon, 5 August 2013 01:26:46 -0700, Christoph Hellwig wrote:
> On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
> > The patch looks right to me - we should pass in similar flags for the
> > create case as for tmpfile to the filesystem.
> > 
> > But let's make sure we're all on the same page. Al?
> 
> Given all the problems and very limited fs support I'd much prefer
> disabling O_TMPFILE for this release.  That'd give it the needed
> exposure it was missing by being merged without any previous public
> review.

Agreed.  This has not been in -next at all.  It is not an urgent
security thing or regression fix, so there is no good excuse for
avoiding the normal process.

Jörn

--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
-- Richard Feynman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Oleg Nesterov]

On 08/05, Felipe Contreras wrote:
>
> On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov  wrote:
> >
> > Hmm. It should not crash under strace... please see below.
> >
> >> 953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not 
> >> permitted)
> >
> > OK, so it actually uses ptrace ;)
> >
> > PTRACE_ATTACH fails because this child is already traced by strace, I guess.
> >
> > So does Starcraft crash this way? Or does it fail in some other way?
>
> It's crashing just the same.

But then it is not clear how fab840f can make any difference.

wine can not use ptrace when it runs after "strace -f". But, to remind,
I know nothing about wine. Perhaps wine uses some daemons which actually
run/ptrace the workload?

> > And just in case... perhaps wine does some logging too?
>
> Yeah, but there doesn't seem to be anything interesting:
>
> http://bugs.winehq.org/attachment.cgi?id=45489

at least there is certainly nothing interesting for me since
I don't understand this ;) Thanks.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Felipe Contreras]

On Mon, Aug 5, 2013 at 9:39 AM, Oleg Nesterov  wrote:
> On 08/05, Felipe Contreras wrote:
>>
>> On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov  wrote:
>> >
>> > Could you please run wine under strace
>> >
>> > strace -f -e ptrace -o LOG wine ...
>> >
>> > and show the result?
>>
>> Sure.
>
> Thanks.
>
>> Note that the crash might have happened some time before the end
>> of the log.
>
> Hmm. It should not crash under strace... please see below.
>
>> 953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
>
> OK, so it actually uses ptrace ;)
>
> PTRACE_ATTACH fails because this child is already traced by strace, I guess.
>
> So does Starcraft crash this way? Or does it fail in some other way?

It's crashing just the same.

> And just in case... perhaps wine does some logging too?

Yeah, but there doesn't seem to be anything interesting:

http://bugs.winehq.org/attachment.cgi?id=45489

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Oleg Nesterov]

On 08/05, Felipe Contreras wrote:
>
> On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov  wrote:
> >
> > Could you please run wine under strace
> >
> > strace -f -e ptrace -o LOG wine ...
> >
> > and show the result?
>
> Sure.

Thanks.

> Note that the crash might have happened some time before the end
> of the log.

Hmm. It should not crash under strace... please see below.

> 953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)

OK, so it actually uses ptrace ;)

PTRACE_ATTACH fails because this child is already traced by strace, I guess.

So does Starcraft crash this way? Or does it fail in some other way?

And just in case... perhaps wine does some logging too?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_TMPFILE fs corruption (Re: Linux 3.11-rc4)

[Al Viro]

On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
> The patch looks right to me - we should pass in similar flags for the
> create case as for tmpfile to the filesystem.
> 
> But let's make sure we're all on the same page. Al?

ACK.  It used to happen as a side effect of O_CREAT being required
in the flags, but that broke once we switched to use of O_DIRECTORY.

I've applied both Andi's patches (along with one from Zheng Liu) in
vfs.git #for-linus.  Another thing in there is reiserfs umount
deadlock fix - that one needs to go in all branches starting from
2.6.23.

Please, pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

Shortlog:
Al Viro (1):
  reiserfs: fix deadlock in umount

Andy Lutomirski (2):
  fs: Fix file mode for O_TMPFILE
  fs: Allow unprivileged linkat(..., AT_EMPTY_PATH) aka flink

Zheng Liu (1):
  vfs: add missing check for __O_TMPFILE in fcntl_init()

Diffstat:
 fs/fcntl.c   |4 +-
 fs/namei.c   |   10 ++
 fs/open.c|2 +-
 fs/reiserfs/procfs.c |   99 ++
 fs/reiserfs/super.c  |3 +-
 5 files changed, 26 insertions(+), 92 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Felipe Contreras]

On Mon, Aug 5, 2013 at 8:29 AM, Oleg Nesterov  wrote:
> On 08/04, Felipe Contreras wrote:
>>
>> I found a regression while running all v3.11-rcX kernels; Starcract II
>> through wine crashes.
>
> Thanks... just to clarify, Starcract crashes, wine or kernel?

It's Starcraft. In fact, it detects the crash and tries to send a bug
report to Blizzard, the company behind it.

>> The culprit is fab840f (ptrace: PTRACE_DETACH
>> should do flush_ptrace_hw_breakpoint(child)), I revert that commit and
>> there's no crash.
>
> I never used wine, but I am puzzled anyway. This patch really looks
> like a simple and minor bugfix.
>
> Could you please run wine under strace
>
> strace -f -e ptrace -o LOG wine ...
>
> and show the result?

Sure. Note that the crash might have happened some time before the end
of the log.

951   +++ exited with 0 +++
952   +++ exited with 0 +++
950   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=952,
si_status=0, si_utime=0, si_stime=0} ---
954   +++ exited with 0 +++
956   +++ exited with 0 +++
955   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=956,
si_status=0, si_utime=0, si_stime=0} ---
958   +++ exited with 0 +++
955   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=958,
si_status=0, si_utime=0, si_stime=0} ---
962   +++ exited with 0 +++
959   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=962,
si_status=0, si_utime=0, si_stime=0} ---
961   +++ exited with 0 +++
970   +++ exited with 0 +++
959   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=970,
si_status=0, si_utime=0, si_stime=0} ---
965   +++ exited with 0 +++
977   +++ exited with 0 +++
957   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=977,
si_status=0, si_utime=0, si_stime=0} ---
955   +++ exited with 0 +++
950   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=954,
si_status=0, si_utime=0, si_stime=0} ---
980   --- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=953,
si_uid=1000} ---
988   +++ exited with 0 +++
986   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=988,
si_status=0, si_utime=0, si_stime=0} ---
993   +++ exited with 0 +++
989   --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=993,
si_status=0, si_utime=0, si_stime=0} ---
995   +++ exited with 0 +++
992   +++ exited with 0 +++
989   +++ exited with 0 +++
1009  +++ exited with 0 +++
1010  +++ exited with 0 +++
1011  +++ exited with 0 +++
1012  +++ exited with 0 +++
1013  +++ exited with 0 +++
1014  +++ exited with 0 +++
1016  --- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=953,
si_uid=1000} ---
1016  +++ exited with 0 +++
1018  +++ exited with 0 +++
1020  +++ exited with 0 +++
1021  +++ exited with 0 +++
1022  +++ exited with 0 +++
974   +++ exited with 0 +++
1023  +++ exited with 0 +++
1025  +++ exited with 0 +++
1005  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1025,
si_status=0, si_utime=0, si_stime=0} ---
1027  +++ exited with 0 +++
1029  +++ exited with 0 +++
980   +++ exited with 0 +++
986   +++ exited with 0 +++
1032  --- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_TKILL, si_pid=953,
si_uid=1000} ---
1032  +++ exited with 0 +++
1034  +++ exited with 0 +++
1026  --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1034,
si_status=0, si_utime=0, si_stime=0} ---
1036  +++ exited with 0 +++
983   +++ exited with 0 +++
984   +++ exited with 0 +++
991   +++ exited with 0 +++
1031  +++ exited with 0 +++
981   +++ exited with 0 +++
985   --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_TKILL, si_pid=953,
si_uid=1000} ---
982   +++ exited with 0 +++
985   +++ exited with 0 +++
987   +++ exited with 0 +++
990   +++ exited with 0 +++
1030  +++ exited with 0 +++
950   +++ exited with 0 +++
1033  +++ exited with 0 +++
1026  +++ exited with 0 +++
957   +++ exited with 0 +++
1037  +++ exited with 0 +++
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
1041  +++ exited with 0 +++
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
1047  +++ exited with 0 +++
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
1049  +++ exited with 0 +++
1050  +++ exited with 0 +++
1051  +++ exited with 0 +++
1052  +++ exited with 0 +++
1053  +++ exited with 0 +++
1054  +++ exited with 0 +++
1028  +++ exited with 0 +++
1056  +++ exited with 0 +++
1057  +++ exited with 0 +++
953   ptrace(PTRACE_ATTACH, 1035, 0, 0) = -1 EPERM (Operation not permitted)
953   

Re: Linux 3.11-rc4

[Oleg Nesterov]

On 08/04, Felipe Contreras wrote:
>
> I found a regression while running all v3.11-rcX kernels; Starcract II
> through wine crashes.

Thanks... just to clarify, Starcract crashes, wine or kernel?

> The culprit is fab840f (ptrace: PTRACE_DETACH
> should do flush_ptrace_hw_breakpoint(child)), I revert that commit and
> there's no crash.

I never used wine, but I am puzzled anyway. This patch really looks
like a simple and minor bugfix.

Could you please run wine under strace

strace -f -e ptrace -o LOG wine ...

and show the result?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_TMPFILE fs corruption (Re: Linux 3.11-rc4)

[Christoph Hellwig]

On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
> The patch looks right to me - we should pass in similar flags for the
> create case as for tmpfile to the filesystem.
> 
> But let's make sure we're all on the same page. Al?

Given all the problems and very limited fs support I'd much prefer
disabling O_TMPFILE for this release.  That'd give it the needed
exposure it was missing by being merged without any previous public
review.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: O_TMPFILE fs corruption (Re: Linux 3.11-rc4)

[Christoph Hellwig]

On Sun, Aug 04, 2013 at 08:45:16PM -0700, Linus Torvalds wrote:
 The patch looks right to me - we should pass in similar flags for the
 create case as for tmpfile to the filesystem.
 
 But let's make sure we're all on the same page. Al?

Given all the problems and very limited fs support I'd much prefer
disabling O_TMPFILE for this release.  That'd give it the needed
exposure it was missing by being merged without any previous public
review.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc4

[Oleg Nesterov]

On 08/04, Felipe Contreras wrote:

 I found a regression while running all v3.11-rcX kernels; Starcract II
 through wine crashes.

Thanks... just to clarify, Starcract crashes, wine or kernel?

 The culprit is fab840f (ptrace: PTRACE_DETACH
 should do flush_ptrace_hw_breakpoint(child)), I revert that commit and
 there's no crash.

I never used wine, but I am puzzled anyway. This patch really looks
like a simple and minor bugfix.

Could you please run wine under strace

strace -f -e ptrace -o LOG wine ...

and show the result?

Oleg.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/