1. 21 Apr, 2017 6 commits
  2. 20 Apr, 2017 15 commits
  3. 19 Apr, 2017 9 commits
    • Cong Wang's avatar
      nsfs: mark dentry with DCACHE_RCUACCESS · 073c516f
      Cong Wang authored
      Andrey reported a use-after-free in __ns_get_path():
      
        spin_lock include/linux/spinlock.h:299 [inline]
        lockref_get_not_dead+0x19/0x80 lib/lockref.c:179
        __ns_get_path+0x197/0x860 fs/nsfs.c:66
        open_related_ns+0xda/0x200 fs/nsfs.c:143
        sock_ioctl+0x39d/0x440 net/socket.c:1001
        vfs_ioctl fs/ioctl.c:45 [inline]
        do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
        SYSC_ioctl fs/ioctl.c:700 [inline]
        SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
      
      We are under rcu read lock protection at that point:
      
              rcu_read_lock();
              d = atomic_long_read(&ns->stashed);
              if (!d)
                      goto slow;
              dentry = (struct dentry *)d;
              if (!lockref_get_not_dead(&dentry->d_lockref))
                      goto slow;
              rcu_read_unlock();
      
      but don't use a proper RCU API on the free path, therefore a parallel
      __d_free() could free it at the same time.  We need to mark the stashed
      dentry with DCACHE_RCUACCESS so that __d_free() will be called after all
      readers leave RCU.
      
      Fixes: e149ed2b ("take the targets of /proc/*/ns/* symlinks to separate fs")
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      073c516f
    • Michal Hocko's avatar
      mm: make mm_percpu_wq non freezable · 80d136e1
      Michal Hocko authored
      Geert has reported a freeze during PM resume and some additional
      debugging has shown that the device_resume worker cannot make a forward
      progress because it waits for an event which is stuck waiting in
      drain_all_pages:
      
        INFO: task kworker/u4:0:5 blocked for more than 120 seconds.
              Not tainted 4.11.0-rc7-koelsch-00029-g005882e5-dirty #3476
        "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
        kworker/u4:0    D    0     5      2 0x00000000
        Workqueue: events_unbound async_run_entry_fn
          __schedule
          schedule
          schedule_timeout
          wait_for_common
          dpm_wait_for_superior
          device_resume
          async_resume
          async_run_entry_fn
          process_one_work
          worker_thread
          kthread
        [...]
        bash            D    0  1703   1694 0x00000000
          __schedule
          schedule
          schedule_timeout
          wait_for_common
          flush_work
          drain_all_pages
          start_isolate_page_range
          alloc_contig_range
          cma_alloc
          __alloc_from_contiguous
          cma_allocator_alloc
          __dma_alloc
          arm_dma_alloc
          sh_eth_ring_init
          sh_eth_open
          sh_eth_resume
          dpm_run_callback
          device_resume
          dpm_resume
          dpm_resume_end
          suspend_devices_and_enter
          pm_suspend
          state_store
          kernfs_fop_write
          __vfs_write
          vfs_write
          SyS_write
        [...]
        Showing busy workqueues and worker pools:
        [...]
        workqueue mm_percpu_wq: flags=0xc
          pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=0/0
            delayed: drain_local_pages_wq, vmstat_update
          pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=0/0
            delayed: drain_local_pages_wq BAR(1703), vmstat_update
      
      Tetsuo has properly noted that mm_percpu_wq is created as WQ_FREEZABLE
      so it is frozen this early during resume so we are effectively
      deadlocked.  Fix this by dropping WQ_FREEZABLE when creating
      mm_percpu_wq.  We really want to have it operational all the time.
      
      Fixes: ce612879 ("mm: move pcp and lru-pcp draining into single wq")
      Reported-and-tested-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Debugged-by: default avatarTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      80d136e1
    • Linus Torvalds's avatar
      Merge tag 'backlight-for-v4.11' of git://git.linaro.org/people/daniel.thompson/linux · c4bac97b
      Linus Torvalds authored
      Pull backlight fix from Daniel Thompson:
       "Normally pull requests for backlight come from Lee Jones (and will
        continue to do so) but the bug fixed here is annoying for few people
        so I'm providing a little holiday cover.
      
        Fix a single bug in the PWM backlight driver and make it play nice
        with a wider range of GPIO devices. This bug is a regression and was
        independently discovered by Geert Uytterhoevan and Paul Kocialkowski
        (and is tested by both)"
      
      * tag 'backlight-for-v4.11' of git://git.linaro.org/people/daniel.thompson/linux:
        backlight: pwm_bl: Fix GPIO out for unimplemented .get_direction()
      c4bac97b
    • Arnd Bergmann's avatar
      ACPI / power: Avoid maybe-uninitialized warning · fe8c470a
      Arnd Bergmann authored
      gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state()
      is enterered at least once, so it assumes that cur_state might not get
      initialized:
      
      drivers/acpi/power.c: In function 'acpi_power_get_inferred_state':
      drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      This sets the variable to zero at the start of the loop, to ensure that
      there is well-defined behavior even for an empty list. This gets rid of
      the warning.
      
      The warning first showed up when the -Os flag got removed in a bug fix
      patch in linux-4.11-rc5.
      
      I would suggest merging this addon patch on top of that bug fix to avoid
      introducing a new warning in the stable kernels.
      
      Fixes: 61b79e16 (ACPI: Fix incompatibility with mcount-based function graph tracing)
      Cc: All applicable <stable@vger.kernel.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fe8c470a
    • Ming Lei's avatar
      mtip32xx: pass BLK_MQ_F_NO_SCHED · 4981d04d
      Ming Lei authored
      The recent introduced MQ IO scheduler breaks mtip32xx in the
      following way.
      
      mtip32xx use the 'request_index' passed to .init_request() as
      hardware tag index for initializing hardware queue, and it
      actually require that rq->tag is always same with 'request_index'
      passed to .init_request(). Current blk-mq IO scheduler can't
      guarantee this point, so this patch passes BLK_MQ_F_NO_SCHED
      and at least make mtip32xx working.
      
      This patch fixes the following strange hardware failure. The
      issue can be triggered easily when doing I/O with mq-deadline
      enabled.
      
      [  186.972578] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 32993
      [  186.972578] {1}[Hardware Error]: event severity: fatal
      [  186.972579] {1}[Hardware Error]:  Error 0, type: fatal
      [  186.972580] {1}[Hardware Error]:   section_type: PCIe error
      [  186.972580] {1}[Hardware Error]:   port_type: 0, PCIe end point
      [  186.972581] {1}[Hardware Error]:   version: 1.0
      [  186.972581] {1}[Hardware Error]:   command: 0x0407, status: 0x0010
      [  186.972582] {1}[Hardware Error]:   device_id: 0000:07:00.0
      [  186.972582] {1}[Hardware Error]:   slot: 4
      [  186.972583] {1}[Hardware Error]:   secondary_bus: 0x00
      [  186.972583] {1}[Hardware Error]:   vendor_id: 0x1344, device_id: 0x5150
      [  186.972584] {1}[Hardware Error]:   class_code: 008001
      [  186.972585] Kernel panic - not syncing: Fatal hardware error!
      Reported-by: default avatarJozef Mikovic <jmikovic@redhat.com>
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      4981d04d
    • Ming Lei's avatar
      block: respect BLK_MQ_F_NO_SCHED · 3a5088c8
      Ming Lei authored
      If one driver claims that it doesn't support io scheduler via
      BLK_MQ_F_NO_SCHED, we should not allow to change and show the
      availabe io schedulers.
      
      This patch adds check to enhance this behaviour.
      Signed-off-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      3a5088c8
    • Geert Uytterhoeven's avatar
      backlight: pwm_bl: Fix GPIO out for unimplemented .get_direction() · 892c7788
      Geert Uytterhoeven authored
      Commit 7613c922 ("backlight: pwm_bl: Move the checks for initial
      power state to a separate function") not just moved some code, but made
      slight changes in semantics.
      
      If a gpiochip doesn't implement the optional .get_direction() callback,
      gpiod_get_direction always returns -EINVAL, which is never equal to
      GPIOF_DIR_IN, leading to the GPIO not being configured for output.
      
      To avoid this, invert the test and check for not GPIOF_DIR_OUT instead,
      like the original code did.
      
      This restores the display on r8a7740/armadillo.
      
      Fixes: 7613c922 ("backlight: pwm_bl: Move the checks for initial power state to a separate function")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Acked-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Acked-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      892c7788
    • Steven Rostedt (VMware)'s avatar
      tracing: Allocate the snapshot buffer before enabling probe · df62db5b
      Steven Rostedt (VMware) authored
      Currently the snapshot trigger enables the probe and then allocates the
      snapshot. If the probe triggers before the allocation, it could cause the
      snapshot to fail and turn tracing off. It's best to allocate the snapshot
      buffer first, and then enable the trigger. If something goes wrong in the
      enabling of the trigger, the snapshot buffer is still allocated, but it can
      also be freed by the user by writting zero into the snapshot buffer file.
      
      Also add a check of the return status of alloc_snapshot().
      
      Cc: stable@vger.kernel.org
      Fixes: 77fd5c15 ("tracing: Add snapshot trigger to function probes")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      df62db5b
    • Jason Gerecke's avatar
      HID: wacom: Treat HID_DG_TOOLSERIALNUMBER as unsigned · 286f3f47
      Jason Gerecke authored
      Because HID_DG_TOOLSERIALNUMBER doesn't first cast the value recieved from HID
      to an unsigned type, sign-extension rules can cause the value of
      wacom_wac->serial[0] to inadvertently wind up with all 32 of its highest bits
      set if the highest bit of "value" was set.
      
      This can cause problems for Tablet PC devices which use AES sensors and the
      xf86-input-wacom userspace driver. It is not uncommon for AES sensors to send a
      serial number of '0' while the pen is entering or leaving proximity. The
      xf86-input-wacom driver ignores events with a serial number of '0' since it
      cannot match them up to an in-use tool.  To ensure the xf86-input-wacom driver
      does not ignore the final out-of-proximity event, the kernel does not send
      MSC_SERIAL events when the value of wacom_wac->serial[0] is '0'. If the highest
      bit of HID_DG_TOOLSERIALNUMBER is set by an in-prox pen which later leaves
      proximity and sends a '0' for HID_DG_TOOLSERIALNUMBER, then only the lowest 32
      bits of wacom_wac->serial[0] are actually cleared, causing the kernel to send
      an MSC_SERIAL event. Since the 'input_event' function takes an 'int' as
      argument, only those lowest (now-cleared) 32 bits of wacom_wac->serial[0] are
      sent to userspace, causing xf86-input-wacom to ignore the event. If the event
      was the final out-of-prox event, then xf86-input-wacom may remain in a state
      where it believes the pen is in proximity and refuses to allow other devices
      under its control (e.g. the touchscreen) to move the cursor.
      
      It should be noted that EMR devices and devices which use both the
      HID_DG_TOOLSERIALNUMBER and WACOM_HID_WD_SERIALHI usages (in that order) would
      be immune to this issue. It appears only AES devices are affected.
      
      Fixes: f85c9dc6 ("HID: wacom: generic: Support tool ID and additional tool types")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJason Gerecke <jason.gerecke@wacom.com>
      Acked-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      286f3f47
  4. 18 Apr, 2017 10 commits
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc · 005882e5
      Linus Torvalds authored
      Pull sparc fixes from David Miller:
       "Two Sparc bug fixes from Daniel Jordan and Nitin Gupta"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
        sparc64: Fix hugepage page table free
        sparc64: Use LOCKDEP_SMALL, not PROVE_LOCKING_SMALL
      005882e5
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 40d9018e
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) BPF tail call handling bug fixes from Daniel Borkmann.
      
       2) Fix allowance of too many rx queues in sfc driver, from Bert
          Kenward.
      
       3) Non-loopback ipv6 packets claiming src of ::1 should be dropped,
          from Florian Westphal.
      
       4) Statistics requests on KSZ9031 can crash, fix from Grygorii
          Strashko.
      
       5) TX ring handling fixes in mediatek driver, from Sean Wang.
      
       6) ip_ra_control can deadlock, fix lock acquisition ordering to fix,
          from Cong WANG.
      
       7) Fix use after free in ip_recv_error(), from Willem de Buijn.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        bpf: fix checking xdp_adjust_head on tail calls
        bpf: fix cb access in socket filter programs on tail calls
        ipv6: drop non loopback packets claiming to originate from ::1
        net: ethernet: mediatek: fix inconsistency of port number carried in TXD
        net: ethernet: mediatek: fix inconsistency between TXD and the used buffer
        net: phy: micrel: fix crash when statistic requested for KSZ9031 phy
        net: vrf: Fix setting NLM_F_EXCL flag when adding l3mdev rule
        net: thunderx: Fix set_max_bgx_per_node for 81xx rgx
        net-timestamp: avoid use-after-free in ip_recv_error
        ipv4: fix a deadlock in ip_ra_control
        sfc: limit the number of receive queues
      40d9018e
    • Nitin Gupta's avatar
      sparc64: Fix hugepage page table free · 544f8f93
      Nitin Gupta authored
      Make sure the start adderess is aligned to PMD_SIZE
      boundary when freeing page table backing a hugepage
      region. The issue was causing segfaults when a region
      backed by 64K pages was unmapped since such a region
      is in general not PMD_SIZE aligned.
      Signed-off-by: default avatarNitin Gupta <nitin.m.gupta@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      544f8f93
    • Daniel Jordan's avatar
      sparc64: Use LOCKDEP_SMALL, not PROVE_LOCKING_SMALL · 395102db
      Daniel Jordan authored
      CONFIG_PROVE_LOCKING_SMALL shrinks the memory usage of lockdep so the
      kernel text, data, and bss fit in the required 32MB limit, but this
      option is not set for every config that enables lockdep.
      
      A 4.10 kernel fails to boot with the console output
      
          Kernel: Using 8 locked TLB entries for main kernel image.
          hypervisor_tlb_lock[2000000:0:8000000071c007c3:1]: errors with f
          Program terminated
      
      with these config options
      
          CONFIG_LOCKDEP=y
          CONFIG_LOCK_STAT=y
          CONFIG_PROVE_LOCKING=n
      
      To fix, rename CONFIG_PROVE_LOCKING_SMALL to CONFIG_LOCKDEP_SMALL, and
      enable this option with CONFIG_LOCKDEP=y so we get the reduced memory
      usage every time lockdep is turned on.
      
      Tested that CONFIG_LOCKDEP_SMALL is set to 'y' if and only if
      CONFIG_LOCKDEP is set to 'y'.  When other lockdep-related config options
      that select CONFIG_LOCKDEP are enabled (e.g. CONFIG_LOCK_STAT or
      CONFIG_PROVE_LOCKING), verified that CONFIG_LOCKDEP_SMALL is also
      enabled.
      
      Fixes: e6b5f1be ("config: Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc")
      Signed-off-by: default avatarDaniel Jordan <daniel.m.jordan@oracle.com>
      Reviewed-by: default avatarBabu Moger <babu.moger@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      395102db
    • Douglas Anderson's avatar
      mmc: dw_mmc: Don't allow Runtime PM for SDIO cards · a6db2c86
      Douglas Anderson authored
      According to the SDIO standard interrupts are normally signalled in a
      very complicated way.  They require the card clock to be running and
      require the controller to be paying close attention to the signals
      coming from the card.  This simply can't happen with the clock stopped
      or with the controller in a low power mode.
      
      To that end, we'll disable runtime_pm when we detect that an SDIO card
      was inserted.  This is much like with what we do with the special
      "SDMMC_CLKEN_LOW_PWR" bit that dw_mmc supports.
      
      NOTE: we specifically do this Runtime PM disabling at card init time
      rather than in the enable_sdio_irq() callback.  This is _different_
      than how SDHCI does it.  Why do we do it differently?
      
      - Unlike SDHCI, dw_mmc uses the standard sdio_irq code in Linux (AKA
        dw_mmc doesn't set MMC_CAP2_SDIO_IRQ_NOTHREAD).
      - Because we use the standard sdio_irq code:
        - We see a constant stream of enable_sdio_irq(0) and
          enable_sdio_irq(1) calls.  This is because the standard code
          disables interrupts while processing and re-enables them after.
        - While interrupts are disabled, there's technically a period where
          we could get runtime disabled while processing interrupts.
        - If we are runtime disabled while processing interrupts, we'll
          reset the controller at resume time (see dw_mci_runtime_resume),
          which seems like a terrible idea because we could possibly have
          another interrupt pending.
      
      To fix the above isues we'd want to put something in the standard
      sdio_irq code that makes sure to call pm_runtime get/put when
      interrupts are being actively being processed.  That's possible to do,
      but it seems like a more complicated mechanism when we really just
      want the runtime pm disabled always for SDIO cards given that all the
      other bits needed to get Runtime PM vs. SDIO just aren't there.
      
      NOTE: at some point in time someone might come up with a fancy way to
      do SDIO interrupts and still allow (some) amount of runtime PM.
      Technically we could turn off the card clock if we used an alternate
      way of signaling SDIO interrupts (and out of band interrupt is one way
      to do this).  We probably wouldn't actually want to fully runtime
      suspend in this case though--at least not with the current
      dw_mci_runtime_resume() which basically fully resets the controller at
      resume time.
      
      Fixes: e9ed8835 ("mmc: dw_mmc: add runtime PM callback")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarJaehoon Chung <jh80.chung@samsung.com>
      Reviewed-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      a6db2c86
    • Thorsten Leemhuis's avatar
      Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled · 704de489
      Thorsten Leemhuis authored
      Temporary got a Lifebook E547 into my hands and noticed the touchpad
      only works after running:
      
      	echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled
      
      Add it to the list of machines that need this workaround.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThorsten Leemhuis <linux@leemhuis.info>
      Reviewed-by: default avatarUlrik De Bie <ulrik.debie-os@e2big.org>
      Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      704de489
    • Linus Torvalds's avatar
      Merge tag 'trace-v4.11-rc5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · fb5e2154
      Linus Torvalds authored
      Pull ftrace testcase update from Steven Rostedt:
       "While testing my development branch, without the fix for the pid use
        after free bug, the selftest that Namhyung added triggers it. I
        figured it would be good to add the test for the bug after the fix,
        such that it does not exist without the fix.
      
        I added another patch that lets the test only test part of the pid
        filtering, and ignores the function-fork (filtering on children as
        well) if the function-fork feature does not exist. This feature is
        added by Namhyung just before he added this test. But since the test
        tests both with and without the feature, it would be good to let it
        not fail if the feature does not exist"
      
      * tag 'trace-v4.11-rc5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        selftests: ftrace: Add check for function-fork before running pid filter test
        selftests: ftrace: Add a testcase for function PID filter
      fb5e2154
    • Heiner Kallweit's avatar
      mmc: sdio: fix alignment issue in struct sdio_func · 5ef1ecf0
      Heiner Kallweit authored
      Certain 64-bit systems (e.g. Amlogic Meson GX) require buffers to be
      used for DMA to be 8-byte-aligned. struct sdio_func has an embedded
      small DMA buffer not meeting this requirement.
      When testing switching to descriptor chain mode in meson-gx driver
      SDIO is broken therefore. Fix this by allocating the small DMA buffer
      separately as kmalloc ensures that the returned memory area is
      properly aligned for every basic data type.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Tested-by: default avatarHelmut Klein <hgkr.klein@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      5ef1ecf0
    • Steven Rostedt (VMware)'s avatar
      selftests: ftrace: Add check for function-fork before running pid filter test · 9ed19c76
      Steven Rostedt (VMware) authored
      Have the func-filter-pid test check for the function-fork option before
      testing it. It can still test the pid filtering, but will stop before
      testing the function-fork option for children inheriting the pids.
      This allows the test to be added before the function-fork feature, but after
      a bug fix that triggers one of the bugs the test can cause.
      
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Shuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      9ed19c76
    • Linus Torvalds's avatar
      Merge tag 'trace-v4.11-rc5-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 0bad6d7e
      Linus Torvalds authored
      Pull ftrace fix from Steven Rostedt:
       "Namhyung Kim discovered a use after free bug. It has to do with adding
        a pid filter to function tracing in an instance, and then freeing the
        instance"
      
      * tag 'trace-v4.11-rc5-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        ftrace: Fix function pid filter on instances
      0bad6d7e