1. 02 May, 2019 1 commit
    • YueHaibing's avatar
      fs/proc/proc_sysctl.c: Fix a NULL pointer dereference · 41e09d7e
      YueHaibing authored
      [ Upstream commit 89189557 ]
      
      Syzkaller report this:
      
        sysctl could not get directory: /net//bridge -12
        kasan: CONFIG_KASAN_INLINE enabled
        kasan: GPF could be caused by NULL-ptr deref or user memory access
        general protection fault: 0000 [#1] SMP KASAN PTI
        CPU: 1 PID: 7027 Comm: syz-executor.0 Tainted: G         C        5.1.0-rc3+ #8
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
        RIP: 0010:__write_once_size include/linux/compiler.h:220 [inline]
        RIP: 0010:__rb_change_child include/linux/rbtree_augmented.h:144 [inline]
        RIP: 0010:__rb_erase_augmented include/linux/rbtree_augmented.h:186 [inline]
        RIP: 0010:rb_erase+0x5f4/0x19f0 lib/rbtree.c:459
        Code: 00 0f 85 60 13 00 00 48 89 1a 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 89 f2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 75 0c 00 00 4d 85 ed 4c 89 2e 74 ce 4c 89 ea 48
        RSP: 0018:ffff8881bb507778 EFLAGS: 00010206
        RAX: dffffc0000000000 RBX: ffff8881f224b5b8 RCX: ffffffff818f3f6a
        RDX: 000000000000000a RSI: 0000000000000050 RDI: ffff8881f224b568
        RBP: 0000000000000000 R08: ffffed10376a0ef4 R09: ffffed10376a0ef4
        R10: 0000000000000001 R11: ffffed10376a0ef4 R12: ffff8881f224b558
        R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
        FS:  00007f3e7ce13700(0000) GS:ffff8881f7300000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00007fd60fbe9398 CR3: 00000001cb55c001 CR4: 00000000007606e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        PKRU: 55555554
        Call Trace:
         erase_entry fs/proc/proc_sysctl.c:178 [inline]
         erase_header+0xe3/0x160 fs/proc/proc_sysctl.c:207
         start_unregistering fs/proc/proc_sysctl.c:331 [inline]
         drop_sysctl_table+0x558/0x880 fs/proc/proc_sysctl.c:1631
         get_subdir fs/proc/proc_sysctl.c:1022 [inline]
         __register_sysctl_table+0xd65/0x1090 fs/proc/proc_sysctl.c:1335
         br_netfilter_init+0x68/0x1000 [br_netfilter]
         do_one_initcall+0xbc/0x47d init/main.c:901
         do_init_module+0x1b5/0x547 kernel/module.c:3456
         load_module+0x6405/0x8c10 kernel/module.c:3804
         __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
         do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
        Modules linked in: br_netfilter(+) backlight comedi(C) hid_sensor_hub max3100 ti_ads8688 udc_core fddi snd_mona leds_gpio rc_streamzap mtd pata_netcell nf_log_common rc_winfast udp_tunnel snd_usbmidi_lib snd_usb_toneport snd_usb_line6 snd_rawmidi snd_seq_device snd_hwdep videobuf2_v4l2 videobuf2_common videodev media videobuf2_vmalloc videobuf2_memops rc_gadmei_rm008z 8250_of smm665 hid_tmff hid_saitek hwmon_vid rc_ati_tv_wonder_hd_600 rc_core pata_pdc202xx_old dn_rtmsg as3722 ad714x_i2c ad714x snd_soc_cs4265 hid_kensington panel_ilitek_ili9322 drm drm_panel_orientation_quirks ipack cdc_phonet usbcore phonet hid_jabra hid extcon_arizona can_dev industrialio_triggered_buffer kfifo_buf industrialio adm1031 i2c_mux_ltc4306 i2c_mux ipmi_msghandler mlxsw_core snd_soc_cs35l34 snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer ac97_bus snd_compress snd soundcore gpio_da9055 uio ecdh_generic mdio_thunder of_mdio fixed_phy libphy mdio_cavium iptable_security iptable_raw iptable_mangle
         iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun joydev mousedev ppdev tpm kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel ide_pci_generic piix aes_x86_64 crypto_simd cryptd ide_core glue_helper input_leds psmouse intel_agp intel_gtt serio_raw ata_generic i2c_piix4 agpgart pata_acpi parport_pc parport floppy rtc_cmos sch_fq_codel ip_tables x_tables sha1_ssse3 sha1_generic ipv6 [last unloaded: br_netfilter]
        Dumping ftrace buffer:
           (ftrace buffer empty)
        ---[ end trace 68741688d5fbfe85 ]---
      
      commit 23da9588 ("fs/proc/proc_sysctl.c: fix NULL pointer
      dereference in put_links") forgot to handle start_unregistering() case,
      while header->parent is NULL, it calls erase_header() and as seen in the
      above syzkaller call trace, accessing &header->parent->root will trigger
      a NULL pointer dereference.
      
      As that commit explained, there is also no need to call
      start_unregistering() if header->parent is NULL.
      
      Link: http://lkml.kernel.org/r/20190409153622.28112-1-yuehaibing@huawei.com
      Fixes: 23da9588 ("fs/proc/proc_sysctl.c: fix NULL pointer dereference in put_links")
      Fixes: 0e47c99d ("sysctl: Replace root_list with links between sysctl_table_sets")
      Signed-off-by: 's avatarYueHaibing <yuehaibing@huawei.com>
      Reported-by: 's avatarHulk Robot <hulkci@huawei.com>
      Reviewed-by: 's avatarKees Cook <keescook@chromium.org>
      Cc: Luis Chamberlain <mcgrof@kernel.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      41e09d7e
  2. 27 Apr, 2019 1 commit
    • Andrea Arcangeli's avatar
      coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping · 1eb719f0
      Andrea Arcangeli authored
      commit 04f5866e upstream.
      
      The core dumping code has always run without holding the mmap_sem for
      writing, despite that is the only way to ensure that the entire vma
      layout will not change from under it.  Only using some signal
      serialization on the processes belonging to the mm is not nearly enough.
      This was pointed out earlier.  For example in Hugh's post from Jul 2017:
      
        https://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils
      
        "Not strictly relevant here, but a related note: I was very surprised
         to discover, only quite recently, how handle_mm_fault() may be called
         without down_read(mmap_sem) - when core dumping. That seems a
         misguided optimization to me, which would also be nice to correct"
      
      In particular because the growsdown and growsup can move the
      vm_start/vm_end the various loops the core dump does around the vma will
      not be consistent if page faults can happen concurrently.
      
      Pretty much all users calling mmget_not_zero()/get_task_mm() and then
      taking the mmap_sem had the potential to introduce unexpected side
      effects in the core dumping code.
      
      Adding mmap_sem for writing around the ->core_dump invocation is a
      viable long term fix, but it requires removing all copy user and page
      faults and to replace them with get_dump_page() for all binary formats
      which is not suitable as a short term fix.
      
      For the time being this solution manually covers the places that can
      confuse the core dump either by altering the vma layout or the vma flags
      while it runs.  Once ->core_dump runs under mmap_sem for writing the
      function mmget_still_valid() can be dropped.
      
      Allowing mmap_sem protected sections to run in parallel with the
      coredump provides some minor parallelism advantage to the swapoff code
      (which seems to be safe enough by never mangling any vma field and can
      keep doing swapins in parallel to the core dumping) and to some other
      corner case.
      
      In order to facilitate the backporting I added "Fixes: 86039bd3"
      however the side effect of this same race condition in /proc/pid/mem
      should be reproducible since before 2.6.12-rc2 so I couldn't add any
      other "Fixes:" because there's no hash beyond the git genesis commit.
      
      Because find_extend_vma() is the only location outside of the process
      context that could modify the "mm" structures under mmap_sem for
      reading, by adding the mmget_still_valid() check to it, all other cases
      that take the mmap_sem for reading don't need the new check after
      mmget_not_zero()/get_task_mm().  The expand_stack() in page fault
      context also doesn't need the new check, because all tasks under core
      dumping are frozen.
      
      Link: http://lkml.kernel.org/r/20190325224949.11068-1-aarcange@redhat.com
      Fixes: 86039bd3 ("userfaultfd: add new syscall to provide memory externalization")
      Signed-off-by: 's avatarAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: 's avatarJann Horn <jannh@google.com>
      Suggested-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: 's avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: 's avatarMike Rapoport <rppt@linux.ibm.com>
      Reviewed-by: 's avatarOleg Nesterov <oleg@redhat.com>
      Reviewed-by: 's avatarJann Horn <jannh@google.com>
      Acked-by: 's avatarJason Gunthorpe <jgg@mellanox.com>
      Acked-by: 's avatarMichal Hocko <mhocko@suse.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1eb719f0
  3. 20 Apr, 2019 1 commit
    • Kairui Song's avatar
      x86/gart: Exclude GART aperture from kcore · 64253073
      Kairui Song authored
      [ Upstream commit ffc8599a ]
      
      On machines where the GART aperture is mapped over physical RAM,
      /proc/kcore contains the GART aperture range. Accessing the GART range via
      /proc/kcore results in a kernel crash.
      
      vmcore used to have the same issue, until it was fixed with commit
      2a3e83c6 ("x86/gart: Exclude GART aperture from vmcore")', leveraging
      existing hook infrastructure in vmcore to let /proc/vmcore return zeroes
      when attempting to read the aperture region, and so it won't read from the
      actual memory.
      
      Apply the same workaround for kcore. First implement the same hook
      infrastructure for kcore, then reuse the hook functions introduced in the
      previous vmcore fix. Just with some minor adjustment, rename some functions
      for more general usage, and simplify the hook infrastructure a bit as there
      is no module usage yet.
      Suggested-by: 's avatarBaoquan He <bhe@redhat.com>
      Signed-off-by: 's avatarKairui Song <kasong@redhat.com>
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: 's avatarJiri Bohac <jbohac@suse.cz>
      Acked-by: 's avatarBaoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Omar Sandoval <osandov@fb.com>
      Cc: Dave Young <dyoung@redhat.com>
      Link: https://lkml.kernel.org/r/20190308030508.13548-1-kasong@redhat.comSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      64253073
  4. 03 Apr, 2019 1 commit
    • YueHaibing's avatar
      fs/proc/proc_sysctl.c: fix NULL pointer dereference in put_links · 79d8bdf3
      YueHaibing authored
      commit 23da9588 upstream.
      
      Syzkaller reports:
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN PTI
      CPU: 1 PID: 5373 Comm: syz-executor.0 Not tainted 5.0.0-rc8+ #3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:put_links+0x101/0x440 fs/proc/proc_sysctl.c:1599
      Code: 00 0f 85 3a 03 00 00 48 8b 43 38 48 89 44 24 20 48 83 c0 38 48 89 c2 48 89 44 24 28 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 fe 02 00 00 48 8b 74 24 20 48 c7 c7 60 2a 9d 91
      RSP: 0018:ffff8881d828f238 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: ffff8881e01b1140 RCX: ffffffff8ee98267
      RDX: 0000000000000007 RSI: ffffc90001479000 RDI: ffff8881e01b1178
      RBP: dffffc0000000000 R08: ffffed103ee27259 R09: ffffed103ee27259
      R10: 0000000000000001 R11: ffffed103ee27258 R12: fffffffffffffff4
      R13: 0000000000000006 R14: ffff8881f59838c0 R15: dffffc0000000000
      FS:  00007f072254f700(0000) GS:ffff8881f7100000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fff8b286668 CR3: 00000001f0542002 CR4: 00000000007606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       drop_sysctl_table+0x152/0x9f0 fs/proc/proc_sysctl.c:1629
       get_subdir fs/proc/proc_sysctl.c:1022 [inline]
       __register_sysctl_table+0xd65/0x1090 fs/proc/proc_sysctl.c:1335
       br_netfilter_init+0xbc/0x1000 [br_netfilter]
       do_one_initcall+0xfa/0x5ca init/main.c:887
       do_init_module+0x204/0x5f6 kernel/module.c:3460
       load_module+0x66b2/0x8570 kernel/module.c:3808
       __do_sys_finit_module+0x238/0x2a0 kernel/module.c:3902
       do_syscall_64+0x147/0x600 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x462e99
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f072254ec58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
      RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
      RDX: 0000000000000000 RSI: 0000000020000280 RDI: 0000000000000003
      RBP: 00007f072254ec70 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f072254f6bc
      R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
      Modules linked in: br_netfilter(+) dvb_usb_dibusb_mc_common dib3000mc dibx000_common dvb_usb_dibusb_common dvb_usb_dw2102 dvb_usb classmate_laptop palmas_regulator cn videobuf2_v4l2 v4l2_common snd_soc_bd28623 mptbase snd_usb_usx2y snd_usbmidi_lib snd_rawmidi wmi libnvdimm lockd sunrpc grace rc_kworld_pc150u rc_core rtc_da9063 sha1_ssse3 i2c_cros_ec_tunnel adxl34x_spi adxl34x nfnetlink lib80211 i5500_temp dvb_as102 dvb_core videobuf2_common videodev media videobuf2_vmalloc videobuf2_memops udc_core lnbp22 leds_lp3952 hid_roccat_ryos s1d13xxxfb mtd vport_geneve openvswitch nf_conncount nf_nat_ipv6 nsh geneve udp_tunnel ip6_udp_tunnel snd_soc_mt6351 sis_agp phylink snd_soc_adau1761_spi snd_soc_adau1761 snd_soc_adau17x1 snd_soc_core snd_pcm_dmaengine ac97_bus snd_compress snd_soc_adau_utils snd_soc_sigmadsp_regmap snd_soc_sigmadsp raid_class hid_roccat_konepure hid_roccat_common hid_roccat c2port_duramar2150 core mdio_bcm_unimac iptable_security iptable_raw iptable_mangle
       iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim devlink vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel joydev mousedev ide_pci_generic piix aesni_intel aes_x86_64 ide_core crypto_simd atkbd cryptd glue_helper serio_raw ata_generic pata_acpi i2c_piix4 floppy sch_fq_codel ip_tables x_tables ipv6 [last unloaded: lm73]
      Dumping ftrace buffer:
         (ftrace buffer empty)
      ---[ end trace 770020de38961fd0 ]---
      
      A new dir entry can be created in get_subdir and its 'header->parent' is
      set to NULL.  Only after insert_header success, it will be set to 'dir',
      otherwise 'header->parent' is set to NULL and drop_sysctl_table is called.
      However in err handling path of get_subdir, drop_sysctl_table also be
      called on 'new->header' regardless its value of parent pointer.  Then
      put_links is called, which triggers NULL-ptr deref when access member of
      header->parent.
      
      In fact we have multiple error paths which call drop_sysctl_table() there,
      upon failure on insert_links() we also call drop_sysctl_table().And even
      in the successful case on __register_sysctl_table() we still always call
      drop_sysctl_table().This patch fix it.
      
      Link: http://lkml.kernel.org/r/20190314085527.13244-1-yuehaibing@huawei.com
      Fixes: 0e47c99d ("sysctl: Replace root_list with links between sysctl_table_sets")
      Signed-off-by: 's avatarYueHaibing <yuehaibing@huawei.com>
      Reported-by: 's avatarHulk Robot <hulkci@huawei.com>
      Acked-by: 's avatarLuis Chamberlain <mcgrof@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: <stable@vger.kernel.org>    [3.4+]
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79d8bdf3
  5. 12 Mar, 2019 1 commit
  6. 04 Mar, 2019 2 commits
    • Alfred Chen's avatar
      PDS-mq 0.99a · cc956dd4
      Alfred Chen authored
      Priority and Deadline based Skiplist multiple queue Scheduler
      Detail document at Documentation/scheduler/sched-PDS-mq.txt
      
      Project git repository at https://gitlab.com/alfredchen/linux-pds
      
      *Updated for Kernel 4.20
      
      -Alfred Chen
      
      pds: select_task_rq() optimization.
      
      pds: pds_load_balance() optimization.
      
      pds: Remove unnecessary code.
      
      pds: pds_sg_balance() optimization.
      
      pds: task_preemptible_rq() optimization.
      
      pds: [Sync] 175f0e25 sched/core: Fix rules for running on online && !active CPUs
      
      Tag PDS 0.98r
      
      pds: Fix compilation issue on raspberry pi.
      
      pds: Rework pds_sg_balance()
      
      Remove sched_cpu_sb_suppress_mask, the first cpu in the smt group will
      not do smt group balance.
      
      pds: Optimize pds_load_balance().
      
      pds: Remove sched_nr_rq_pending.
      
      pds: Fix wrong nr_max_tries in migrate_pending_tasks.
      
      Tag PDS 0.98s
      
      pds: Rework pds_load_balance().
      
      Introduce sched_balance_mask and sched_balance_shift, replaced
      rq->next_balance and rq->balance_inc.
      
      Re-schedule the rq when RQ balance happens, this help with balance
      convergence.
      
      pds: Minor optimization in task_preemptible_rq().
      
      Tag PDS 0.98t
      
      pds: Fix possibe kernel warning in pds_load_balance().
      
      pds: [Sync] c3442697 softirq: Eliminate unused cond_resched_softirq() macro
      
      pds: [Sync] d7822b1e rseq: Introduce restartable sequences system call
      
      pds: [Sync] 0ed557aa sched/core / kcov: avoid kcov_area during task switch
      
      pds: [Sync] d9c0ffca sched/nohz: Skip remote tick on idle task entirely
      
      pds: [Sync] 1cef1150 kthread, sched/core: Fix kthread_parkme() (again...)
      
      Tag PDS 0.98u
      
      pds: Instroduce __update_cpumasks_bitmap()
      
      pds: Instroduce rq nr_running_level.
      
      pds: Use trylock when pick tasks from other rq.
      
      pds: CPU affinity check start from llc in take_other_rq_task()
      
      Instroduce sched_cpu_llc_start_mask, which take_other_rq_task() start
      affinity check from.
      The sched_cpu_affinity_chk_masks for coregroup now also include the smt
      cpu.
      
      pds: Batch tasks don't preempt.
      
      Batch tasks don't try to preempt any NORMAL/BATCH tasks but only IDLE policy
      tasks.
      
      pds: Rework check_preempt_curr()
      
      1. Reschedule if rq->curr is idle tasks.
      2. Batch&Idle policy tasks doesn't preempt rq->curr
      3. Otherwise, reschedule rq->curr if p has higher priority and deadline
      
      pds: Remove wake_flags that no longer be used.
      
      Tag PDS 0.98v
      
      pds: Rework rq->sl_header data structure.
      
      pds: Fix possible task lost in migrate_tasks().
      
      After rq data structure changed, it's possible a running task be losted
      in migrate_tasks().
      This commit change migrate_tasks() logic to what mainline kernel is
      using.
      
      pds: Policy based task_preemptible_rq().
      
      pds: Rewrok take_other_rq_task() code path.
      
      migrate_pending_tasks() now skip running tasks, migrate the first
      non-running task which allowed to run on dest-cpu then repeat every two
      tasks.
      Max attempt of migration is the min of (rq->nr_running + 1) /2 and
      SCHED_RQ_NR_MIGRATIONSCHED_RQ_NR_MIGRATION, this allow tasks on a
      suspended rq(which has tasks in run queue but unable to run for scheduler
      reason) to be migrated to other run queues.
      A filter priority has been introduced, the migration will be stopped
      when reach task at this priority.
      
      pds: Change per cpu cpu_has_smt_sibling to sched_sibling_cpu.
      
      pds: try to take tasks from other rq when prio downgrade.
      
      pds: Introduce sched_rq_pending_masks.
      
      Introduce sched_rq_pending_masks, which just like sched_rq_queued_maks,
      which represent the second task running level of cpus.
      The rq which has two or more tasks in queue now is
      ~sched_rq_pending_masks[SCHED_RQ_EMPTY]
      
      The origin sched_rq_nr_running_masks has been removed.
      
      pds: Fix UP/non-SMT compilation warning.
      
      Tag PDS 0.98w
      
      pds: cgroup stub.
      
      pds: Revert "Rework rq->sl_header data structure"
      
      Tag PDS 0.98x
      
      pds: Enable SMT_NICE scheduling.
      
      Firstly, look at the kernel compilation test result without(-j4) and with SMT(-j8).
      
      Without SMT(-j4)	With SMT(-j8)
      4m30s			3m40s
      
      In the scenario IDLE and NORMAL(BATCH,ISO,RT) policy tasks run together,
      IDLE tasks can be supressed to run on SMT sibling cpus and let the other
      policy tasks run without SMT. In this way, tasks with other policy will
      take high priority and completed sooner than run with IDLE tasks on SMT
      sibling cpus. This is called the SMT_NICE scheduling.
      
      Below is the test results of SMT_NICE disabled and SMT_NICE enabled.
      
      		SMT_NICE disabled	SMT_NICE enabled
      NORMAL(-j4)	6m56s			5m3s
      IDLE(-j4)	7m10s			8m30s
      
      Tag PDS 0.98y
      
      pds: Replace task_queued() by task_on_rq_queued().
      
      pds: Don't balance on an idle task.
      
      pds: Improve idle task SMT_NICE handling in ttwu.
      
      pds: Re-mapping SCHED_DEADLINE to SCHED_FIFO
      
      Tag PDS 0.98z
      
      pds: Fix sugov_kthread_create fail to set policy.
      
      Fix issue in sugov_kthread_create(), faile to set SHCED_DEADLINE.
      
      "cpufreq_schedutil: sugov_kthread_create: failed to set SCHED_DEADLINE"
      
      pds: Fix task burst fairness issue.
      
      In task burst creation scinario, frame drops are observed in mpv.
      New created tasks occupied more time slices than the parent has.
      
      Tag PDS 0.99a
      cc956dd4
    • Oleksandr Natalenko's avatar
      a0371111
  7. 21 Feb, 2019 1 commit
  8. 13 Feb, 2019 1 commit
  9. 01 Feb, 2019 1 commit
  10. 04 Jan, 2019 4 commits
  11. 28 Dec, 2018 5 commits
  12. 14 Dec, 2018 1 commit
    • Ivan Delalande's avatar
      proc/sysctl: don't return ENOMEM on lookup when a table is unregistering · ea5751cc
      Ivan Delalande authored
      proc_sys_lookup can fail with ENOMEM instead of ENOENT when the
      corresponding sysctl table is being unregistered. In our case we see
      this upon opening /proc/sys/net/*/conf files while network interfaces
      are being deleted, which confuses our configuration daemon.
      
      The problem was successfully reproduced and this fix tested on v4.9.122
      and v4.20-rc6.
      
      v2: return ERR_PTRs in all cases when proc_sys_make_inode fails instead
      of mixing them with NULL. Thanks Al Viro for the feedback.
      
      Fixes: ace0c791 ("proc/sysctl: Don't grab i_lock under sysctl_lock.")
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarIvan Delalande <colona@arista.com>
      Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
      ea5751cc
  13. 31 Oct, 2018 2 commits
  14. 26 Oct, 2018 4 commits
    • Johannes Weiner's avatar
      mm: zero-seek shrinkers · 4b85afbd
      Johannes Weiner authored
      The page cache and most shrinkable slab caches hold data that has been
      read from disk, but there are some caches that only cache CPU work, such
      as the dentry and inode caches of procfs and sysfs, as well as the subset
      of radix tree nodes that track non-resident page cache.
      
      Currently, all these are shrunk at the same rate: using DEFAULT_SEEKS for
      the shrinker's seeks setting tells the reclaim algorithm that for every
      two page cache pages scanned it should scan one slab object.
      
      This is a bogus setting.  A virtual inode that required no IO to create is
      not twice as valuable as a page cache page; shadow cache entries with
      eviction distances beyond the size of memory aren't either.
      
      In most cases, the behavior in practice is still fine.  Such virtual
      caches don't tend to grow and assert themselves aggressively, and usually
      get picked up before they cause problems.  But there are scenarios where
      that's not true.
      
      Our database workloads suffer from two of those.  For one, their file
      workingset is several times bigger than available memory, which has the
      kernel aggressively create shadow page cache entries for the non-resident
      parts of it.  The workingset code does tell the VM that most of these are
      expendable, but the VM ends up balancing them 2:1 to cache pages as per
      the seeks setting.  This is a huge waste of memory.
      
      These workloads also deal with tens of thousands of open files and use
      /proc for introspection, which ends up growing the proc_inode_cache to
      absurdly large sizes - again at the cost of valuable cache space, which
      isn't a reasonable trade-off, given that proc inodes can be re-created
      without involving the disk.
      
      This patch implements a "zero-seek" setting for shrinkers that results in
      a target ratio of 0:1 between their objects and IO-backed caches.  This
      allows such virtual caches to grow when memory is available (they do
      cache/avoid CPU work after all), but effectively disables them as soon as
      IO-backed objects are under pressure.
      
      It then switches the shrinkers for procfs and sysfs metadata, as well as
      excess page cache shadow nodes, to the new zero-seek setting.
      
      Link: http://lkml.kernel.org/r/20181009184732.762-5-hannes@cmpxchg.orgSigned-off-by: 's avatarJohannes Weiner <hannes@cmpxchg.org>
      Reported-by: 's avatarDomas Mituzas <dmituzas@fb.com>
      Reviewed-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: 's avatarRik van Riel <riel@surriel.com>
      Acked-by: 's avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      4b85afbd
    • Johannes Weiner's avatar
      sched: loadavg: consolidate LOAD_INT, LOAD_FRAC, CALC_LOAD · 8508cf3f
      Johannes Weiner authored
      There are several definitions of those functions/macros in places that
      mess with fixed-point load averages.  Provide an official version.
      
      [akpm@linux-foundation.org: fix missed conversion in block/blk-iolatency.c]
      Link: http://lkml.kernel.org/r/20180828172258.3185-5-hannes@cmpxchg.orgSigned-off-by: 's avatarJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: 's avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Tested-by: 's avatarSuren Baghdasaryan <surenb@google.com>
      Tested-by: 's avatarDaniel Drake <drake@endlessm.com>
      Cc: Christopher Lameter <cl@linux.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Johannes Weiner <jweiner@fb.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Enderborg <peter.enderborg@sony.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Shakeel Butt <shakeelb@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Vinayak Menon <vinmenon@codeaurora.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      8508cf3f
    • Vlastimil Babka's avatar
      mm, proc: add KReclaimable to /proc/meminfo · 61f94e18
      Vlastimil Babka authored
      The vmstat NR_KERNEL_MISC_RECLAIMABLE counter is for kernel non-slab
      allocations that can be reclaimed via shrinker.  In /proc/meminfo, we can
      show the sum of all reclaimable kernel allocations (including slab) as
      "KReclaimable".  Add the same counter also to per-node meminfo under /sys
      
      With this counter, users will have more complete information about kernel
      memory usage.  Non-slab reclaimable pages (currently just the ION
      allocator) will not be missing from /proc/meminfo, making users wonder
      where part of their memory went.  More precisely, they already appear in
      MemAvailable, but without the new counter, it's not obvious why the value
      in MemAvailable doesn't fully correspond with the sum of other counters
      participating in it.
      
      Link: http://lkml.kernel.org/r/20180731090649.16028-6-vbabka@suse.czSigned-off-by: 's avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: 's avatarRoman Gushchin <guro@fb.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Vijayanand Jitta <vjitta@codeaurora.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      61f94e18
    • Vlastimil Babka's avatar
      mm: /proc/pid/smaps_rollup: fix NULL pointer deref in smaps_pte_range() · fa76da46
      Vlastimil Babka authored
      Leonardo reports an apparent regression in 4.19-rc7:
      
       BUG: unable to handle kernel NULL pointer dereference at 00000000000000f0
       PGD 0 P4D 0
       Oops: 0000 [#1] PREEMPT SMP PTI
       CPU: 3 PID: 6032 Comm: python Not tainted 4.19.0-041900rc7-lowlatency #201810071631
       Hardware name: LENOVO 80UG/Toronto 4A2, BIOS 0XCN45WW 08/09/2018
       RIP: 0010:smaps_pte_range+0x32d/0x540
       Code: 80 00 00 00 00 74 a9 48 89 de 41 f6 40 52 40 0f 85 04 02 00 00 49 2b 30 48 c1 ee 0c 49 03 b0 98 00 00 00 49 8b 80 a0 00 00 00 <48> 8b b8 f0 00 00 00 e8 b7 ef ec ff 48 85 c0 0f 84 71 ff ff ff a8
       RSP: 0018:ffffb0cbc484fb88 EFLAGS: 00010202
       RAX: 0000000000000000 RBX: 0000560ddb9e9000 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: 0000000560ddb9e9 RDI: 0000000000000001
       RBP: ffffb0cbc484fbc0 R08: ffff94a5a227a578 R09: ffff94a5a227a578
       R10: 0000000000000000 R11: 0000560ddbbe7000 R12: ffffe903098ba728
       R13: ffffb0cbc484fc78 R14: ffffb0cbc484fcf8 R15: ffff94a5a2e9cf48
       FS:  00007f6dfb683740(0000) GS:ffff94a5aaf80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00000000000000f0 CR3: 000000011c118001 CR4: 00000000003606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        __walk_page_range+0x3c2/0x6f0
        walk_page_vma+0x42/0x60
        smap_gather_stats+0x79/0xe0
        ? gather_pte_stats+0x320/0x320
        ? gather_hugetlb_stats+0x70/0x70
        show_smaps_rollup+0xcd/0x1c0
        seq_read+0x157/0x400
        __vfs_read+0x3a/0x180
        ? security_file_permission+0x93/0xc0
        ? security_file_permission+0x93/0xc0
        vfs_read+0x8f/0x140
        ksys_read+0x55/0xc0
        __x64_sys_read+0x1a/0x20
        do_syscall_64+0x5a/0x110
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Decoded code matched to local compilation+disassembly points to
      smaps_pte_entry():
      
              } else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
                                                              && pte_none(*pte))) {
                      page = find_get_entry(vma->vm_file->f_mapping,
                                                      linear_page_index(vma, addr));
      
      Here, vma->vm_file is NULL.  mss->check_shmem_swap should be false in that
      case, however for smaps_rollup, smap_gather_stats() can set the flag true
      for one vma and leave it true for subsequent vma's where it should be
      false.
      
      To fix, reset the check_shmem_swap flag to false.  There's also related
      bug which sets mss->swap to shmem_swapped, which in the context of
      smaps_rollup overwrites any value accumulated from previous vma's.  Fix
      that as well.
      
      Note that the report suggests a regression between 4.17.19 and 4.19-rc7,
      which makes the 4.19 series ending with commit 258f669e ("mm:
      /proc/pid/smaps_rollup: convert to single value seq_file") suspicious.
      But the mss was reused for rollup since 493b0e9d ("mm: add
      /proc/pid/smaps_rollup") so let's play it safe with the stable backport.
      
      Link: http://lkml.kernel.org/r/555fbd1f-4ac9-0b58-dcd4-5dc4380ff7ca@suse.cz
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201377
      Fixes: 493b0e9d ("mm: add /proc/pid/smaps_rollup")
      Signed-off-by: 's avatarVlastimil Babka <vbabka@suse.cz>
      Reported-by: 's avatarLeonardo Soares Müller <leozinho29_eu@hotmail.com>
      Tested-by: 's avatarLeonardo Soares Müller <leozinho29_eu@hotmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Daniel Colascione <dancol@google.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      fa76da46
  15. 09 Oct, 2018 1 commit
  16. 06 Oct, 2018 1 commit
  17. 05 Oct, 2018 1 commit
    • Jann Horn's avatar
      proc: restrict kernel stack dumps to root · f8a00cef
      Jann Horn authored
      Currently, you can use /proc/self/task/*/stack to cause a stack walk on
      a task you control while it is running on another CPU.  That means that
      the stack can change under the stack walker.  The stack walker does
      have guards against going completely off the rails and into random
      kernel memory, but it can interpret random data from your kernel stack
      as instruction pointers and stack pointers.  This can cause exposure of
      kernel stack contents to userspace.
      
      Restrict the ability to inspect kernel stacks of arbitrary tasks to root
      in order to prevent a local attacker from exploiting racy stack unwinding
      to leak kernel task stack contents.  See the added comment for a longer
      rationale.
      
      There don't seem to be any users of this userspace API that can't
      gracefully bail out if reading from the file fails.  Therefore, I believe
      that this change is unlikely to break things.  In the case that this patch
      does end up needing a revert, the next-best solution might be to fake a
      single-entry stack based on wchan.
      
      Link: http://lkml.kernel.org/r/20180927153316.200286-1-jannh@google.com
      Fixes: 2ec220e2 ("proc: add /proc/*/stack")
      Signed-off-by: 's avatarJann Horn <jannh@google.com>
      Acked-by: 's avatarKees Cook <keescook@chromium.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Ken Chen <kenchen@google.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8a00cef
  18. 30 Sep, 2018 1 commit
    • Matthew Wilcox's avatar
      xarray: Replace exceptional entries · 3159f943
      Matthew Wilcox authored
      Introduce xarray value entries and tagged pointers to replace radix
      tree exceptional entries.  This is a slight change in encoding to allow
      the use of an extra bit (we can now store BITS_PER_LONG - 1 bits in a
      value entry).  It is also a change in emphasis; exceptional entries are
      intimidating and different.  As the comment explains, you can choose
      to store values or pointers in the xarray and they are both first-class
      citizens.
      Signed-off-by: 's avatarMatthew Wilcox <willy@infradead.org>
      Reviewed-by: 's avatarJosef Bacik <jbacik@fb.com>
      3159f943
  19. 20 Sep, 2018 1 commit
  20. 04 Sep, 2018 1 commit
  21. 24 Aug, 2018 1 commit
  22. 22 Aug, 2018 7 commits