Linux 4.8-rc1

Linux 4.8-rc1

[Linus Torvalds]

It's been two weeks, and the merge window for 4.8 is thus closed.

Due to travel last week, I actually still have a few pull requests
pending in my inbox that I just wanted to take another look at before
merging, but the large bulk of the merge window material has been
merged, and I wanted to make sure there aren't any new ones coming in.

This seems to be building up to be one of the bigger releases lately,
but let's see how it all ends up. The merge window has been fairly
normal, although the patch itself looks somewhat unusual: over 20% of
the patch is documentation updates, due to conversion of the drm and
media documentation from docbook to the Sphinx doc format. There are
other doc updates, but that's the big bulk of it.

If you ignore the documentation format change, things look fairly
regular, with about 60% of the non-documentation diffs being drivers
(gpu, networking, media, sound, etc)  and about 15% being arch updates
(arm, powerpc and x86 dominate, but there's mips and s390 too).

The rest is spread out - core networking, tooling (mainly perf),
include files, core kernel, vfs and low-level filesystems (xfs stands
out). Few areas escaped:

  10787 files changed, 612208 insertions(+), 272098 deletions(-)

Go out and test. The diffs and logs are too big to post, so as usual
for rc1, I'm just appending my "merge log" for a very high-level view.

                Linus

---

Al Viro (3):
    vfs updates
    qstr constification updates
    more vfs updates

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andrew Morton (5):
    updates
    more updates
    yet more updates
    even more updates
    misc fixes

Bjorn Andersson (2):
    remoteproc updates
    hwspinlock updates

Bjorn Helgaas (1):
    PCI updates

Bob Peterson (1):
    gfs2 updates

Borislav Petkov (1):
    EDAC updates

Brian Norris (1):
    MTD updates

Bruce Fields (1):
    nfsd updates

Catalin Marinas (1):
    arm64 updates

Chris Mason (2):
    btrfs updates
    more btrfs updates

Chris Metcalf (1):
    tile architecture updates

Christoph Hellwig (2):
    configfs update
    freevxfs updates

Corey Minyard (1):
    IPMI updates

Dan Williams (1):
    libnvdimm updates

Darren Hart (1):
    x8 platform driver updates

Dave Airlie (3):
    drm updates
    i915 drm fixes
    drm zpos property support

Dave Chinner (2):
    xfs updates
    more xfs updates

David Miller (4):
    networking updates
    sparc updates
    IDE updates
    networking fixes

David Teigland (1):
    dlm updates

David Vrabel (1):
    xen updates

Dmitry Torokhov (2):
    input updates
    more input updates

Doug Ledford (2):
    base rdma updates
    second round of rdma updates

Eric Biederman (1):
    userns vfs updates

Greg KH (5):
    char/misc driver updates
    staging and IIO driver updates
    tty/serial driver updates
    USB updates
    more USB updates

Greg Ungerer (1):
    m68knommu updates

Guenter Roeck (2):
    hwmon updates
    more hwmon updates

Hans-Christian Noren Egtvedt (1):
    AVR32 updates

Helge Deller (1):
    parisc updates

Herbert Xu (2):
    crypto updates
    crypto fixes

Ilya Dryomov (1):
    Ceph updates

Ingo Molnar (21):
    RCU updates
    EFI updates
    locking updates
    RAS updates
    perf updates
    scheduler updates
    NOHZ updates
    x86/apic updates
    x86 mm updates
    x86 boot updates
    x86 build updates
    x86 cleanups
    x86 stackdump update
    x86 fpu updates
    x86 platform updates
    x86 timer updates
    x86 fix
    perf fixes
    x86 header cleanups
    x86 fixes
    perf updates

Jacek Anaszewski (1):
    LED updates

Jaegeuk Kim (1):
    f2fs updates

James Bottomley (3):
    SCSI updates
    SCSI fixes
    binfmt_misc update

James Hogan (1):
    metag architecture updates

James Morris (1):
    security subsystem updates

Jan Kara (1):
    quota update

Jens Axboe (4):
    core block updates
    block driver updates
    block fixes
    more block fixes

Jiri Kosina (2):
    trivial tree updates
    HID updates

Joerg Roedel (1):
    IOMMU updates

Jon Mason (1):
    NTB updates

Jonathan Corbet (2):
    documentation updates
    documentation fixes

Jussi Brar (1):
    mailbox updates

Kees Cook (2):
    pstore subsystem updates
    pstore fixes

Lee Jones (2):
    MFD updates
    backlight updates

Linus Walleij (2):
    GPIO updates
    pin control updates

Mark Brown (3):
    regmap updates
    regulator updates
    spi updates

Martin Brandenburg (1):
    orangefs update

Martin Schwidefsky (2):
    s390 updates
    more s390 updates

Mauro Carvalho Chehab (4):
    media updates
    media documentation updates
    media DocBook removal and some fixups
    mailcap fixlets

Michael Ellerman (2):
    powerpc updates
    more powerpc updates

Michael Tsirkin (1):
    virtio/vhost updates

Michael Turquette (1):
    clk updates

Michal Marek (2):
    kbuild updates
    misc kbuild updates

Mike Mashall (1):
    orangefs updates

Mike Snitzer (2):
    device mapper updates
    device mapper fixes

Miklos Szeredi (2):
    overlayfs update
    fuse updates

Nicholas Bellinger (1):
    SCSI target updates

Olof Johansson (7):
    ARM SoC cleanups
    ARM SoC platform updates
    64-bit ARM SoC updates
    ARM SoC defconfig updates
    ARM SoC driver updates
    ARM DT updates
    64-bit ARM DT updates

Paolo Bonzini (2):
    KVM updates
    more KVM updates

Paul Moore (1):
    audit updates

Radim Krčmář (1):
    KVM leftovers

Rafael Wysocki (7):
    power management updates
    ACPI updates
    PNP update
    power management fix
    more power management updates
    more ACPI updates
    PNP fix

Ralf Baechle (1):
    MIPS updates

Rich Felker (1):
    arch/sh updates

Richard Weinberger (2):
    UML updates
    UBI/UBIFS updates

Rob Herring (1):
    DeviceTree updates

Russell King (1):
    ARM updates

Rusty Russell (1):
    module updates

Sebastian Reichel (2):
    power supply and reset updates
    HSI updates

Shaohua Li (1):
    MD updates

Shuah Khan (2):
    kselftest fixes
    kselftest updates

Simon Horman (1):
    SH drivers updates

Steve French (1):
    CIFS/SMB3 fixes

Steven Rostedt (2):
    tracing updates
    tracing fixes

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (3):
    ext4 updates
    random driver updates
    random driver fix

Tejun Heo (3):
    cgroup updates
    libata updates
    more cgroup updates

Thierry Reding (1):
    pwm updates

Thomas Gleixner (7):
    timer updates
    irq updates
    smp hotplug updates
    misc fixes
    perf fixes
    x86 cpufeature updates
    x86 microcode updates

Tony Luck (1):
    ia64 updates

Trond Myklebust (1):
    NFS client updates

Ulf Hansson (1):
    MMC updates

Vineet Gupta (1):
    ARC updates

Vinod Koul (1):
    dmaengine updates

Will Deacon (1):
    arm64 fixes

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (1):
    i2c updates

Re: Linux 4.8-rc1 Cirrus QEMU crashes on boot.

[Linus Torvalds]

On Mon, Aug 8, 2016 at 1:24 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> Booting up v4.8-rc1 in qemu today I ran I ran into this beautiful oops.
>
> I am just about to head out the door on vacation until the end of the
> month so hopefully I am tossing out enough information to the right
> people.
>
> I have confirmed that disabling CONFIG_DRM_CIRRUS_QEMU avoids this
> crash.
>
> [    0.720167] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> [    0.721348] IP: [<ffffffff8d5ef9ac>] drm_pick_crtcs+0xfc/0x270
> [    0.722249] PGD 0
> [    0.722659] Oops: 0000 [#1] SMP
> [    0.723141] Modules linked in:
> [    0.723643] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1+ #116
> [    0.724602] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> [    0.725450] task: ffff8800bbf28000 task.stack: ffff8800bbf30000
> [    0.726327] RIP: 0010:[<ffffffff8d5ef9ac>]  [<ffffffff8d5ef9ac>] drm_pick_crtcs+0xfc/0x270
> [    0.727648] RSP: 0000:ffff8800bbf33978  EFLAGS: 00010217
> [    0.728444] RAX: ffffffff8d623a20 RBX: 0000000000000000 RCX: ffff8800baf3f860
> [    0.729498] RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff8800baf3f800
> [    0.730626] RBP: ffff8800bbf339f8 R08: 0000000000000000 R09: 0000000000000001
> [    0.731704] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800bbaf3af0
> [    0.732827] R13: ffff8800bbaf3af8 R14: 0000000000000000 R15: ffff8800baf3fc00
> [    0.733863] FS:  0000000000000000(0000) GS:ffff8800bf800000(0000) knlGS:0000000000000000
> [    0.735106] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.735964] CR2: 0000000000000018 CR3: 000000003b219000 CR4: 00000000000006f0
> [    0.737021] Stack:
> [    0.737342]  ffff8800bbf33998 0000000000000246 ffff8800bbaf3b18 ffff8800bbaf3b00
> [    0.738602]  0000100000000001 0000000000000000 ffff8800bbaf3b00 ffff8800baf3f800
> [    0.739807]  0000000300001000 ffff8800bbaf3b18 ffff8800bbf339e8 ffff8800baf3fc00
> [    0.740993] Call Trace:
> [    0.741393]  [<ffffffff8d5efedd>] drm_setup_crtcs+0x3bd/0xb50
> [    0.742252]  [<ffffffff8d0edaa1>] ? mark_held_locks+0x71/0x90
> [    0.743176]  [<ffffffff8db0db6b>] ? __mutex_unlock_slowpath+0xeb/0x1c0
> [    0.744138]  [<ffffffff8d5f08c1>] drm_fb_helper_initial_config+0x81/0x3c0
> [    0.745166]  [<ffffffff8d6110b4>] ? drm_modeset_unlock_all+0x54/0x80
> [    0.746136]  [<ffffffff8d624fe0>] cirrus_fbdev_init+0xa0/0xb0
> [    0.747033]  [<ffffffff8d6245fb>] cirrus_modeset_init+0x18b/0x1e0
> .. snip snip ..
> [    0.771023] Code: e8 ba e1 ff ff 48 8b 55 b8 48 83 f8 01 83 5d c4 ff 48 8b 7d b8 48 8b 82 98 02 00 00 49 8b 57 08 48 8b 40 10 48 8b 92 00 0a 00 00 <48> 83 7a 18 00 74 09 48 85 c0 0f 84 53 01 00 00 ff d0 49 89 c3

This decodes to

   0: e8 ba e1 ff ff       callq  ...
   5: 48 8b 55 b8           mov    -0x48(%rbp),%rdx
   9: 48 83 f8 01           cmp    $0x1,%rax
   d: 83 5d c4 ff           sbbl   $0xffffffff,-0x3c(%rbp)
  11: 48 8b 7d b8           mov    -0x48(%rbp),%rdi
  15: 48 8b 82 98 02 00 00 mov    0x298(%rdx),%rax
  1c: 49 8b 57 08           mov    0x8(%r15),%rdx
  20: 48 8b 40 10           mov    0x10(%rax),%rax
  24: 48 8b 92 00 0a 00 00 mov    0xa00(%rdx),%rdx
  2b:* 48 83 7a 18 00       cmpq   $0x0,0x18(%rdx) <-- trapping instruction
  30: 74 09                 je     0x3b
  32: 48 85 c0             test   %rax,%rax
  35: 0f 84 53 01 00 00     je     0x18e
  3b: ff d0                 callq  *%rax
  3d: 49 89 c3             mov    %rax,%r11


and trying to find matching code I think the oops is from this:

        if (fb_helper->dev->mode_config.funcs->atomic_commit &&
            !connector_funcs->best_encoder)
                encoder = drm_atomic_helper_best_encoder(connector);
        else
                encoder = connector_funcs->best_encoder(connector);

in particular, the trapping instruction is the load of "atomic_commit".

(The "callq *%rax" seems to be the "connector_funcs->best_encoder()" call)

So I *think* we have "fb_helper->dev->mode_config.funcs" being NULL.

But I might have gotten the code matching wrong. I don't have the same
compiler as Eric, so even when using his config my code generation
doesn't really match. But there is only one indirect call in that
function, which is that ->best_encoder() call, so it does seem to
match up.

Adding Boris Brezillon and Daniel Vetter to the cc, since assuming I'm
right, the main suspect is commit c61b93fe51b1 ("drm/atomic: Fix
remaining places where !funcs->best_encoder is valid").

Boris? Daniel?

              Linus

Re: Linux 4.8-rc1 Cirrus QEMU crashes on boot.

[David Airlie]

----- Original Message -----
> From: "Linus Torvalds" <torvalds@linux-foundation.org>
> To: "Eric W. Biederman" <ebiederm@xmission.com>, "Boris Brezillon" <boris.brezillon@free-electrons.com>, "Daniel
> Vetter" <daniel.vetter@ffwll.ch>
> Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Dave Airlie" <airlied@redhat.com>, "David Airlie"
> <airlied@linux.ie>, "DRI" <dri-devel@lists.freedesktop.org>
> Sent: Tuesday, 9 August, 2016 7:19:23 AM
> Subject: Re: Linux 4.8-rc1 Cirrus QEMU crashes on boot.
> 
> On Mon, Aug 8, 2016 at 1:24 PM, Eric W. Biederman <ebiederm@xmission.com>
> wrote:
> >
> > Booting up v4.8-rc1 in qemu today I ran I ran into this beautiful oops.
> >
> > I am just about to head out the door on vacation until the end of the
> > month so hopefully I am tossing out enough information to the right
> > people.
> >
> > I have confirmed that disabling CONFIG_DRM_CIRRUS_QEMU avoids this
> > crash.
> >
> > [    0.720167] BUG: unable to handle kernel NULL pointer dereference at
> > 0000000000000018
> > [    0.721348] IP: [<ffffffff8d5ef9ac>] drm_pick_crtcs+0xfc/0x270
> > [    0.722249] PGD 0
> > [    0.722659] Oops: 0000 [#1] SMP
> > [    0.723141] Modules linked in:
> > [    0.723643] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1+ #116
> > [    0.724602] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> > [    0.725450] task: ffff8800bbf28000 task.stack: ffff8800bbf30000
> > [    0.726327] RIP: 0010:[<ffffffff8d5ef9ac>]  [<ffffffff8d5ef9ac>]
> > drm_pick_crtcs+0xfc/0x270
> > [    0.727648] RSP: 0000:ffff8800bbf33978  EFLAGS: 00010217
> > [    0.728444] RAX: ffffffff8d623a20 RBX: 0000000000000000 RCX:
> > ffff8800baf3f860
> > [    0.729498] RDX: 0000000000000000 RSI: 0000000000001000 RDI:
> > ffff8800baf3f800
> > [    0.730626] RBP: ffff8800bbf339f8 R08: 0000000000000000 R09:
> > 0000000000000001
> > [    0.731704] R10: 0000000000000001 R11: 0000000000000000 R12:
> > ffff8800bbaf3af0
> > [    0.732827] R13: ffff8800bbaf3af8 R14: 0000000000000000 R15:
> > ffff8800baf3fc00
> > [    0.733863] FS:  0000000000000000(0000) GS:ffff8800bf800000(0000)
> > knlGS:0000000000000000
> > [    0.735106] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    0.735964] CR2: 0000000000000018 CR3: 000000003b219000 CR4:
> > 00000000000006f0
> > [    0.737021] Stack:
> > [    0.737342]  ffff8800bbf33998 0000000000000246 ffff8800bbaf3b18
> > ffff8800bbaf3b00
> > [    0.738602]  0000100000000001 0000000000000000 ffff8800bbaf3b00
> > ffff8800baf3f800
> > [    0.739807]  0000000300001000 ffff8800bbaf3b18 ffff8800bbf339e8
> > ffff8800baf3fc00
> > [    0.740993] Call Trace:
> > [    0.741393]  [<ffffffff8d5efedd>] drm_setup_crtcs+0x3bd/0xb50
> > [    0.742252]  [<ffffffff8d0edaa1>] ? mark_held_locks+0x71/0x90
> > [    0.743176]  [<ffffffff8db0db6b>] ? __mutex_unlock_slowpath+0xeb/0x1c0
> > [    0.744138]  [<ffffffff8d5f08c1>]
> > drm_fb_helper_initial_config+0x81/0x3c0
> > [    0.745166]  [<ffffffff8d6110b4>] ? drm_modeset_unlock_all+0x54/0x80
> > [    0.746136]  [<ffffffff8d624fe0>] cirrus_fbdev_init+0xa0/0xb0
> > [    0.747033]  [<ffffffff8d6245fb>] cirrus_modeset_init+0x18b/0x1e0
> > .. snip snip ..
> > [    0.771023] Code: e8 ba e1 ff ff 48 8b 55 b8 48 83 f8 01 83 5d c4 ff 48
> > 8b 7d b8 48 8b 82 98 02 00 00 49 8b 57 08 48 8b 40 10 48 8b 92 00 0a 00 00
> > <48> 83 7a 18 00 74 09 48 85 c0 0f 84 53 01 00 00 ff d0 49 89 c3
> 
> This decodes to
> 
>    0: e8 ba e1 ff ff       callq  ...
>    5: 48 8b 55 b8           mov    -0x48(%rbp),%rdx
>    9: 48 83 f8 01           cmp    $0x1,%rax
>    d: 83 5d c4 ff           sbbl   $0xffffffff,-0x3c(%rbp)
>   11: 48 8b 7d b8           mov    -0x48(%rbp),%rdi
>   15: 48 8b 82 98 02 00 00 mov    0x298(%rdx),%rax
>   1c: 49 8b 57 08           mov    0x8(%r15),%rdx
>   20: 48 8b 40 10           mov    0x10(%rax),%rax
>   24: 48 8b 92 00 0a 00 00 mov    0xa00(%rdx),%rdx
>   2b:* 48 83 7a 18 00       cmpq   $0x0,0x18(%rdx) <-- trapping instruction
>   30: 74 09                 je     0x3b
>   32: 48 85 c0             test   %rax,%rax
>   35: 0f 84 53 01 00 00     je     0x18e
>   3b: ff d0                 callq  *%rax
>   3d: 49 89 c3             mov    %rax,%r11
> 
> 
> and trying to find matching code I think the oops is from this:
> 
>         if (fb_helper->dev->mode_config.funcs->atomic_commit &&
>             !connector_funcs->best_encoder)
>                 encoder = drm_atomic_helper_best_encoder(connector);
>         else
>                 encoder = connector_funcs->best_encoder(connector);
> 
> in particular, the trapping instruction is the load of "atomic_commit".
> 
> (The "callq *%rax" seems to be the "connector_funcs->best_encoder()" call)
> 
> So I *think* we have "fb_helper->dev->mode_config.funcs" being NULL.
> 
> But I might have gotten the code matching wrong. I don't have the same
> compiler as Eric, so even when using his config my code generation
> doesn't really match. But there is only one indirect call in that
> function, which is that ->best_encoder() call, so it does seem to
> match up.
> 
> Adding Boris Brezillon and Daniel Vetter to the cc, since assuming I'm
> right, the main suspect is commit c61b93fe51b1 ("drm/atomic: Fix
> remaining places where !funcs->best_encoder is valid").
> 
> Boris? Daniel?

I figured this out earlier this morning on another thread,

cirrus sets the mode funcs later than other drivers, will send a fix later,
but I need to audit other drivers.

Dave.
> 
>               Linus
> 

Re: Linux 4.8-rc1 Cirrus QEMU crashes on boot.

[Boris Brezillon]

Linus, Eric,

On Mon, 8 Aug 2016 14:19:23 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Aug 8, 2016 at 1:24 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> >
> > Booting up v4.8-rc1 in qemu today I ran I ran into this beautiful oops.
> >
> > I am just about to head out the door on vacation until the end of the
> > month so hopefully I am tossing out enough information to the right
> > people.
> >
> > I have confirmed that disabling CONFIG_DRM_CIRRUS_QEMU avoids this
> > crash.
> >
> > [    0.720167] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
> > [    0.721348] IP: [<ffffffff8d5ef9ac>] drm_pick_crtcs+0xfc/0x270
> > [    0.722249] PGD 0
> > [    0.722659] Oops: 0000 [#1] SMP
> > [    0.723141] Modules linked in:
> > [    0.723643] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1+ #116
> > [    0.724602] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> > [    0.725450] task: ffff8800bbf28000 task.stack: ffff8800bbf30000
> > [    0.726327] RIP: 0010:[<ffffffff8d5ef9ac>]  [<ffffffff8d5ef9ac>] drm_pick_crtcs+0xfc/0x270
> > [    0.727648] RSP: 0000:ffff8800bbf33978  EFLAGS: 00010217
> > [    0.728444] RAX: ffffffff8d623a20 RBX: 0000000000000000 RCX: ffff8800baf3f860
> > [    0.729498] RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff8800baf3f800
> > [    0.730626] RBP: ffff8800bbf339f8 R08: 0000000000000000 R09: 0000000000000001
> > [    0.731704] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8800bbaf3af0
> > [    0.732827] R13: ffff8800bbaf3af8 R14: 0000000000000000 R15: ffff8800baf3fc00
> > [    0.733863] FS:  0000000000000000(0000) GS:ffff8800bf800000(0000) knlGS:0000000000000000
> > [    0.735106] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    0.735964] CR2: 0000000000000018 CR3: 000000003b219000 CR4: 00000000000006f0
> > [    0.737021] Stack:
> > [    0.737342]  ffff8800bbf33998 0000000000000246 ffff8800bbaf3b18 ffff8800bbaf3b00
> > [    0.738602]  0000100000000001 0000000000000000 ffff8800bbaf3b00 ffff8800baf3f800
> > [    0.739807]  0000000300001000 ffff8800bbaf3b18 ffff8800bbf339e8 ffff8800baf3fc00
> > [    0.740993] Call Trace:
> > [    0.741393]  [<ffffffff8d5efedd>] drm_setup_crtcs+0x3bd/0xb50
> > [    0.742252]  [<ffffffff8d0edaa1>] ? mark_held_locks+0x71/0x90
> > [    0.743176]  [<ffffffff8db0db6b>] ? __mutex_unlock_slowpath+0xeb/0x1c0
> > [    0.744138]  [<ffffffff8d5f08c1>] drm_fb_helper_initial_config+0x81/0x3c0
> > [    0.745166]  [<ffffffff8d6110b4>] ? drm_modeset_unlock_all+0x54/0x80
> > [    0.746136]  [<ffffffff8d624fe0>] cirrus_fbdev_init+0xa0/0xb0
> > [    0.747033]  [<ffffffff8d6245fb>] cirrus_modeset_init+0x18b/0x1e0
> > .. snip snip ..
> > [    0.771023] Code: e8 ba e1 ff ff 48 8b 55 b8 48 83 f8 01 83 5d c4 ff 48 8b 7d b8 48 8b 82 98 02 00 00 49 8b 57 08 48 8b 40 10 48 8b 92 00 0a 00 00 <48> 83 7a 18 00 74 09 48 85 c0 0f 84 53 01 00 00 ff d0 49 89 c3  
> 
> This decodes to
> 
>    0: e8 ba e1 ff ff       callq  ...
>    5: 48 8b 55 b8           mov    -0x48(%rbp),%rdx
>    9: 48 83 f8 01           cmp    $0x1,%rax
>    d: 83 5d c4 ff           sbbl   $0xffffffff,-0x3c(%rbp)
>   11: 48 8b 7d b8           mov    -0x48(%rbp),%rdi
>   15: 48 8b 82 98 02 00 00 mov    0x298(%rdx),%rax
>   1c: 49 8b 57 08           mov    0x8(%r15),%rdx
>   20: 48 8b 40 10           mov    0x10(%rax),%rax
>   24: 48 8b 92 00 0a 00 00 mov    0xa00(%rdx),%rdx
>   2b:* 48 83 7a 18 00       cmpq   $0x0,0x18(%rdx) <-- trapping instruction
>   30: 74 09                 je     0x3b
>   32: 48 85 c0             test   %rax,%rax
>   35: 0f 84 53 01 00 00     je     0x18e
>   3b: ff d0                 callq  *%rax
>   3d: 49 89 c3             mov    %rax,%r11
> 
> 
> and trying to find matching code I think the oops is from this:
> 
>         if (fb_helper->dev->mode_config.funcs->atomic_commit &&
>             !connector_funcs->best_encoder)
>                 encoder = drm_atomic_helper_best_encoder(connector);
>         else
>                 encoder = connector_funcs->best_encoder(connector);
> 
> in particular, the trapping instruction is the load of "atomic_commit".
> 
> (The "callq *%rax" seems to be the "connector_funcs->best_encoder()" call)
> 
> So I *think* we have "fb_helper->dev->mode_config.funcs" being NULL.
> 
> But I might have gotten the code matching wrong. I don't have the same
> compiler as Eric, so even when using his config my code generation
> doesn't really match. But there is only one indirect call in that
> function, which is that ->best_encoder() call, so it does seem to
> match up.
> 
> Adding Boris Brezillon and Daniel Vetter to the cc, since assuming I'm
> right, the main suspect is commit c61b93fe51b1 ("drm/atomic: Fix
> remaining places where !funcs->best_encoder is valid").
> 
> Boris? Daniel?

I think you're right, c61b93fe51b1 is likely to be the commit who
introduced this bug. cirrus_driver_load() [1] assigns
mode_config->funcs pointer to &cirrus_mode_funcs only after calling
cirrus_modeset_init() (this function is taking care of initializing all
DRM elements including the fbdev emulation layer), and commit
c61b93fe51b1 introduced a test on mode_config->funcs->atomic_commit in
the fbdev emulation init code, hence the crash.

Re-ordering the init steps like this [2] should fix the problem (Eric,
can you give this patch a try).

Regards,

Boris

[1]http://lxr.free-electrons.com/source/drivers/gpu/drm/cirrus/cirrus_main.c#L166
[2]http://code.bulix.org/jcs6d9-104989

[PATCH] drm/cirrus: Fix NULL pointer dereference when registering the fbdev

[Boris Brezillon]

cirrus_modeset_init() is initializing/registering the emulated fbdev
and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
!funcs->best_encoder is valid"), DRM internals can access/test some of
the fields in mode_config->funcs as part of the fbdev registration
process.
Make sure dev->mode_config.funcs is properly set to avoid dereferencing
a NULL pointer.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: c61b93fe51b1 ("drm/atomic: Fix remaining places where !funcs->best_encoder is valid")
---
Hi Dave,

As discussed on IRC, I'm sending this patch in a proper format. That's
probably better to wait for Eric's feeback before applying it though.

Regards,

Boris
---
 drivers/gpu/drm/cirrus/cirrus_main.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c b/drivers/gpu/drm/cirrus/cirrus_main.c
index 80446e2d3ab6..76bcb43e7c06 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -185,14 +185,23 @@ int cirrus_driver_load(struct drm_device *dev, unsigned long flags)
 		goto out;
 	}
 
+	/*
+	 * cirrus_modeset_init() is initializing/registering the emulated fbdev
+	 * and DRM internals can access/test some of the fields in
+	 * mode_config->funcs as part of the fbdev registration process.
+	 * Make sure dev->mode_config.funcs is properly set to avoid
+	 * dereferencing a NULL pointer.
+	 * FIXME: mode_config.funcs assignment should probably be done in
+	 * cirrus_modeset_init() (that's a common pattern seen in other DRM
+	 * drivers).
+	 */
+	dev->mode_config.funcs = &cirrus_mode_funcs;
 	r = cirrus_modeset_init(cdev);
 	if (r) {
 		dev_err(&dev->pdev->dev, "Fatal error during modeset init: %d\n", r);
 		goto out;
 	}
 
-	dev->mode_config.funcs = (void *)&cirrus_mode_funcs;
-
 	return 0;
 out:
 	cirrus_driver_unload(dev);
-- 
2.7.4

linux-next: stats (Was: Linux 4.8-rc1)

[Stephen Rothwell]

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20160725 was the first linux-next after
the merge window opened.)

Commits in v4.8-rc1 (relative to v4.7):            11618
Commits in next-20160725:                          11061
Commits with the same SHA1:                         9962
Commits with the same patch_id:                      531 (1)
Commits with the same subject line:                   70 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20160725:     10563 90%

Some breakdown of the list of extra commits (relative to next-20160725)
in -rc1:

Top ten first word of commit summary:

     99 ib
     99 drm
     52 xfs
     52 powerpc
     47 mips
     33 pci
     33 net
     26 ceph
     21 drivers
     19 mm

Top ten authors:

     52 darrick.wong@oracle.com
     31 james.hogan@imgtec.com
     24 dean.luick@intel.com
     23 christian.koenig@amd.com
     22 zyan@redhat.com
     17 paul.gortmaker@windriver.com
     17 mpe@ellerman.id.au
     16 ira.weiny@intel.com
     15 weiyj.lk@gmail.com
     15 peter.chen@nxp.com

Top ten commiters:

    142 davem@davemloft.net
    117 dledford@redhat.com
     85 alexander.deucher@amd.com
     60 torvalds@linux-foundation.org
     56 mpe@ellerman.id.au
     52 david@fromorbit.com
     35 ralf@linux-mips.org
     35 bhelgaas@google.com
     34 idryomov@gmail.com
     27 pbonzini@redhat.com

There are also 498 commits in next-20160725 that didn't make it into
v4.8-rc1.

Top ten first word of commit summary:

    144 thermal
     33 arm
     22 mm
     14 coresight
     14 btrfs
     13 rcu
     12 arm64
      9 keys
      8 extcon
      6 fs

Top ten authors:

    127 edubezval@gmail.com
     44 k.kozlowski@samsung.com
     21 paulmck@linux.vnet.ibm.com
     20 akpm@linux-foundation.org
     14 keescook@chromium.org
     12 olof@lixom.net
     11 dhowells@redhat.com
     11 dalias@libc.org
      9 arnd@arndb.de
      8 suzuki.poulose@arm.com

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

    135 sfr@canb.auug.org.au
     81 edubezval@gmail.com
     63 rui.zhang@intel.com
     31 paulmck@linux.vnet.ibm.com
     22 keescook@chromium.org
     17 mathieu.poirier@linaro.org
     16 steven@ubuntu-virtualbox.(none)
     13 dhowells@redhat.com
     12 olof@lixom.net
     10 fdmanana@suse.com

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] drm/cirrus: Fix NULL pointer dereference when registering the fbdev

[Eric W. Biederman]

Boris Brezillon <boris.brezillon@free-electrons.com> writes:

> cirrus_modeset_init() is initializing/registering the emulated fbdev
> and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
> !funcs->best_encoder is valid"), DRM internals can access/test some of
> the fields in mode_config->funcs as part of the fbdev registration
> process.
> Make sure dev->mode_config.funcs is properly set to avoid dereferencing
> a NULL pointer.

That fixes the issues I am seeing.

Tested-by: "Eric W. Biederman" <ebiederm@xmission.com>

> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Fixes: c61b93fe51b1 ("drm/atomic: Fix remaining places where !funcs->best_encoder is valid")
> ---
> Hi Dave,
>
> As discussed on IRC, I'm sending this patch in a proper format. That's
> probably better to wait for Eric's feeback before applying it though.

It is weird I didn't see either of your email messages directly only
through lkml.  Weird.

> Regards,
>
> Boris
> ---
>  drivers/gpu/drm/cirrus/cirrus_main.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 80446e2d3ab6..76bcb43e7c06 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -185,14 +185,23 @@ int cirrus_driver_load(struct drm_device *dev, unsigned long flags)
>  		goto out;
>  	}
>  
> +	/*
> +	 * cirrus_modeset_init() is initializing/registering the emulated fbdev
> +	 * and DRM internals can access/test some of the fields in
> +	 * mode_config->funcs as part of the fbdev registration process.
> +	 * Make sure dev->mode_config.funcs is properly set to avoid
> +	 * dereferencing a NULL pointer.
> +	 * FIXME: mode_config.funcs assignment should probably be done in
> +	 * cirrus_modeset_init() (that's a common pattern seen in other DRM
> +	 * drivers).
> +	 */
> +	dev->mode_config.funcs = &cirrus_mode_funcs;
>  	r = cirrus_modeset_init(cdev);
>  	if (r) {
>  		dev_err(&dev->pdev->dev, "Fatal error during modeset init: %d\n", r);
>  		goto out;
>  	}
>  
> -	dev->mode_config.funcs = (void *)&cirrus_mode_funcs;
> -
>  	return 0;
>  out:
>  	cirrus_driver_unload(dev);

Re: [PATCH] drm/cirrus: Fix NULL pointer dereference when registering the fbdev

[Boris Brezillon]

On Mon, 08 Aug 2016 22:36:13 -0500
ebiederm@xmission.com (Eric W. Biederman) wrote:

> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
> 
> > cirrus_modeset_init() is initializing/registering the emulated fbdev
> > and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
> > !funcs->best_encoder is valid"), DRM internals can access/test some of
> > the fields in mode_config->funcs as part of the fbdev registration
> > process.
> > Make sure dev->mode_config.funcs is properly set to avoid dereferencing
> > a NULL pointer.  
> 
> That fixes the issues I am seeing.
> 
> Tested-by: "Eric W. Biederman" <ebiederm@xmission.com>
> 
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > Fixes: c61b93fe51b1 ("drm/atomic: Fix remaining places where !funcs->best_encoder is valid")
> > ---
> > Hi Dave,
> >
> > As discussed on IRC, I'm sending this patch in a proper format. That's
> > probably better to wait for Eric's feeback before applying it though.  
> 
> It is weird I didn't see either of your email messages directly only
> through lkml.  Weird.

Probably because of that

"
<ebiederm@xmission.com>: host mx.xmission.com[166.70.12.20] said:
    550-XM-RJCT22: [37.187.137.238] is prohibited from connecting to
XMission mail 550-servers due to high spam volume. See the following
for more information: 550
    http://postmaster.xmission.com/senders/rbls.php?check_rbl=Submit&address=37.187.137.238
    (in reply to RCPT TO command)
"

I filled a form to add this IP to the xmission whitelist, let's see if
you receive my answer :).