1. 24 6月, 2020 9 次提交
  2. 10 6月, 2020 1 次提交
  3. 27 5月, 2020 1 次提交
    • D
      vt: keyboard: avoid signed integer overflow in k_ascii · b86dab05
      Dmitry Torokhov 提交于
      When k_ascii is invoked several times in a row there is a potential for
      signed integer overflow:
      
      UBSAN: Undefined behaviour in drivers/tty/vt/keyboard.c:888:19 signed integer overflow:
      10 * 1111111111 cannot be represented in type 'int'
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.11 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0xce/0x128 lib/dump_stack.c:118
       ubsan_epilogue+0xe/0x30 lib/ubsan.c:154
       handle_overflow+0xdc/0xf0 lib/ubsan.c:184
       __ubsan_handle_mul_overflow+0x2a/0x40 lib/ubsan.c:205
       k_ascii+0xbf/0xd0 drivers/tty/vt/keyboard.c:888
       kbd_keycode drivers/tty/vt/keyboard.c:1477 [inline]
       kbd_event+0x888/0x3be0 drivers/tty/vt/keyboard.c:1495
      
      While it can be worked around by using check_mul_overflow()/
      check_add_overflow(), it is better to introduce a separate flag to
      signal that number pad is being used to compose a symbol, and
      change type of the accumulator from signed to unsigned, thus
      avoiding undefined behavior when it overflows.
      Reported-by: NKyungtae Kim <kt0755@gmail.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200525232740.GA262061@dtor-wsSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b86dab05
  4. 04 5月, 2020 1 次提交
  5. 23 4月, 2020 2 次提交
  6. 16 4月, 2020 2 次提交
  7. 27 3月, 2020 2 次提交
    • E
      vt: vt_ioctl: fix use-after-free in vt_in_use() · 7cf64b18
      Eric Biggers 提交于
      vt_in_use() dereferences console_driver->ttys[i] without proper locking.
      This is broken because the tty can be closed and freed concurrently.
      
      We could fix this by using 'READ_ONCE(console_driver->ttys[i]) != NULL'
      and skipping the check of tty_struct::count.  But, looking at
      console_driver->ttys[i] isn't really appropriate anyway because even if
      it is NULL the tty can still be in the process of being closed.
      
      Instead, fix it by making vt_in_use() require console_lock() and check
      whether the vt is allocated and has port refcount > 1.  This works since
      following the patch "vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use
      virtual console" the port refcount is incremented while the vt is open.
      
      Reproducer (very unreliable, but it worked for me after a few minutes):
      
      	#include <fcntl.h>
      	#include <linux/vt.h>
      
      	int main()
      	{
      		int fd, nproc;
      		struct vt_stat state;
      		char ttyname[16];
      
      		fd = open("/dev/tty10", O_RDONLY);
      		for (nproc = 1; nproc < 8; nproc *= 2)
      			fork();
      		for (;;) {
      			sprintf(ttyname, "/dev/tty%d", rand() % 8);
      			close(open(ttyname, O_RDONLY));
      			ioctl(fd, VT_GETSTATE, &state);
      		}
      	}
      
      KASAN report:
      
      	BUG: KASAN: use-after-free in vt_in_use drivers/tty/vt/vt_ioctl.c:48 [inline]
      	BUG: KASAN: use-after-free in vt_ioctl+0x1ad3/0x1d70 drivers/tty/vt/vt_ioctl.c:657
      	Read of size 4 at addr ffff888065722468 by task syz-vt2/132
      
      	CPU: 0 PID: 132 Comm: syz-vt2 Not tainted 5.6.0-rc5-00130-g089b6d36 #13
      	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20191223_100556-anatol 04/01/2014
      	Call Trace:
      	 [...]
      	 vt_in_use drivers/tty/vt/vt_ioctl.c:48 [inline]
      	 vt_ioctl+0x1ad3/0x1d70 drivers/tty/vt/vt_ioctl.c:657
      	 tty_ioctl+0x9db/0x11b0 drivers/tty/tty_io.c:2660
      	 [...]
      
      	Allocated by task 136:
      	 [...]
      	 kzalloc include/linux/slab.h:669 [inline]
      	 alloc_tty_struct+0x96/0x8a0 drivers/tty/tty_io.c:2982
      	 tty_init_dev+0x23/0x350 drivers/tty/tty_io.c:1334
      	 tty_open_by_driver drivers/tty/tty_io.c:1987 [inline]
      	 tty_open+0x3ca/0xb30 drivers/tty/tty_io.c:2035
      	 [...]
      
      	Freed by task 41:
      	 [...]
      	 kfree+0xbf/0x200 mm/slab.c:3757
      	 free_tty_struct+0x8d/0xb0 drivers/tty/tty_io.c:177
      	 release_one_tty+0x22d/0x2f0 drivers/tty/tty_io.c:1468
      	 process_one_work+0x7f1/0x14b0 kernel/workqueue.c:2264
      	 worker_thread+0x8b/0xc80 kernel/workqueue.c:2410
      	 [...]
      
      Fixes: 4001d7b7 ("vt: push down the tty lock so we can see what is left to tackle")
      Cc: <stable@vger.kernel.org> # v3.4+
      Acked-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Link: https://lore.kernel.org/r/20200322034305.210082-3-ebiggers@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cf64b18
    • E
      vt: vt_ioctl: fix VT_DISALLOCATE freeing in-use virtual console · ca4463bf
      Eric Biggers 提交于
      The VT_DISALLOCATE ioctl can free a virtual console while tty_release()
      is still running, causing a use-after-free in con_shutdown().  This
      occurs because VT_DISALLOCATE considers a virtual console's
      'struct vc_data' to be unused as soon as the corresponding tty's
      refcount hits 0.  But actually it may be still being closed.
      
      Fix this by making vc_data be reference-counted via the embedded
      'struct tty_port'.  A newly allocated virtual console has refcount 1.
      Opening it for the first time increments the refcount to 2.  Closing it
      for the last time decrements the refcount (in tty_operations::cleanup()
      so that it happens late enough), as does VT_DISALLOCATE.
      
      Reproducer:
      	#include <fcntl.h>
      	#include <linux/vt.h>
      	#include <sys/ioctl.h>
      	#include <unistd.h>
      
      	int main()
      	{
      		if (fork()) {
      			for (;;)
      				close(open("/dev/tty5", O_RDWR));
      		} else {
      			int fd = open("/dev/tty10", O_RDWR);
      
      			for (;;)
      				ioctl(fd, VT_DISALLOCATE, 5);
      		}
      	}
      
      KASAN report:
      	BUG: KASAN: use-after-free in con_shutdown+0x76/0x80 drivers/tty/vt/vt.c:3278
      	Write of size 8 at addr ffff88806a4ec108 by task syz_vt/129
      
      	CPU: 0 PID: 129 Comm: syz_vt Not tainted 5.6.0-rc2 #11
      	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20191223_100556-anatol 04/01/2014
      	Call Trace:
      	 [...]
      	 con_shutdown+0x76/0x80 drivers/tty/vt/vt.c:3278
      	 release_tty+0xa8/0x410 drivers/tty/tty_io.c:1514
      	 tty_release_struct+0x34/0x50 drivers/tty/tty_io.c:1629
      	 tty_release+0x984/0xed0 drivers/tty/tty_io.c:1789
      	 [...]
      
      	Allocated by task 129:
      	 [...]
      	 kzalloc include/linux/slab.h:669 [inline]
      	 vc_allocate drivers/tty/vt/vt.c:1085 [inline]
      	 vc_allocate+0x1ac/0x680 drivers/tty/vt/vt.c:1066
      	 con_install+0x4d/0x3f0 drivers/tty/vt/vt.c:3229
      	 tty_driver_install_tty drivers/tty/tty_io.c:1228 [inline]
      	 tty_init_dev+0x94/0x350 drivers/tty/tty_io.c:1341
      	 tty_open_by_driver drivers/tty/tty_io.c:1987 [inline]
      	 tty_open+0x3ca/0xb30 drivers/tty/tty_io.c:2035
      	 [...]
      
      	Freed by task 130:
      	 [...]
      	 kfree+0xbf/0x1e0 mm/slab.c:3757
      	 vt_disallocate drivers/tty/vt/vt_ioctl.c:300 [inline]
      	 vt_ioctl+0x16dc/0x1e30 drivers/tty/vt/vt_ioctl.c:818
      	 tty_ioctl+0x9db/0x11b0 drivers/tty/tty_io.c:2660
      	 [...]
      
      Fixes: 4001d7b7 ("vt: push down the tty lock so we can see what is left to tackle")
      Cc: <stable@vger.kernel.org> # v3.4+
      Reported-by: syzbot+522643ab5729b0421998@syzkaller.appspotmail.com
      Acked-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Link: https://lore.kernel.org/r/20200322034305.210082-2-ebiggers@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ca4463bf
  8. 16 3月, 2020 4 次提交
  9. 13 3月, 2020 2 次提交
  10. 06 3月, 2020 6 次提交
  11. 28 2月, 2020 2 次提交
    • J
      vt: selection, push sel_lock up · e8c75a30
      Jiri Slaby 提交于
      sel_lock cannot nest in the console lock. Thanks to syzkaller, the
      kernel states firmly:
      
      > WARNING: possible circular locking dependency detected
      > 5.6.0-rc3-syzkaller #0 Not tainted
      > ------------------------------------------------------
      > syz-executor.4/20336 is trying to acquire lock:
      > ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
      >
      > but task is already holding lock:
      > ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
      >
      > which lock already depends on the new lock.
      >
      > the existing dependency chain (in reverse order) is:
      >
      > -> #2 (sel_lock){+.+.}:
      >        mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118
      >        set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217
      >        set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181
      >        tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050
      >        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
      
      This is ioctl(TIOCL_SETSEL).
      Locks held on the path: console_lock -> sel_lock
      
      > -> #1 (console_lock){+.+.}:
      >        console_lock+0x46/0x70 kernel/printk/printk.c:2289
      >        con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223
      >        n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350
      >        do_tty_write drivers/tty/tty_io.c:962 [inline]
      >        tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046
      
      This is write().
      Locks held on the path: termios_rwsem -> console_lock
      
      > -> #0 (&tty->termios_rwsem){++++}:
      >        down_write+0x57/0x140 kernel/locking/rwsem.c:1534
      >        tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
      >        mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902
      >        tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465
      >        paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389
      >        tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055
      >        vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
      
      This is ioctl(TIOCL_PASTESEL).
      Locks held on the path: sel_lock -> termios_rwsem
      
      > other info that might help us debug this:
      >
      > Chain exists of:
      >   &tty->termios_rwsem --> console_lock --> sel_lock
      
      Clearly. From the above, we have:
       console_lock -> sel_lock
       sel_lock -> termios_rwsem
       termios_rwsem -> console_lock
      
      Fix this by reversing the console_lock -> sel_lock dependency in
      ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com
      Fixes: 07e6124a ("vt: selection, close sel_buffer race")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e8c75a30
    • J
      vt: selection, push console lock down · 4b70dd57
      Jiri Slaby 提交于
      We need to nest the console lock in sel_lock, so we have to push it down
      a bit. Fortunately, the callers of set_selection_* just lock the console
      lock around the function call. So moving it down is easy.
      
      In the next patch, we switch the order.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Fixes: 07e6124a ("vt: selection, close sel_buffer race")
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200228115406.5735-1-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4b70dd57
  12. 21 2月, 2020 2 次提交
  13. 14 2月, 2020 2 次提交
    • J
      vt: selection, close sel_buffer race · 07e6124a
      Jiri Slaby 提交于
      syzkaller reported this UAF:
      BUG: KASAN: use-after-free in n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741
      Read of size 1 at addr ffff8880089e40e9 by task syz-executor.1/13184
      
      CPU: 0 PID: 13184 Comm: syz-executor.1 Not tainted 5.4.7 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
      Call Trace:
      ...
       kasan_report+0xe/0x20 mm/kasan/common.c:634
       n_tty_receive_buf_common+0x2481/0x2940 drivers/tty/n_tty.c:1741
       tty_ldisc_receive_buf+0xac/0x190 drivers/tty/tty_buffer.c:461
       paste_selection+0x297/0x400 drivers/tty/vt/selection.c:372
       tioclinux+0x20d/0x4e0 drivers/tty/vt/vt.c:3044
       vt_ioctl+0x1bcf/0x28d0 drivers/tty/vt/vt_ioctl.c:364
       tty_ioctl+0x525/0x15a0 drivers/tty/tty_io.c:2657
       vfs_ioctl fs/ioctl.c:47 [inline]
      
      It is due to a race between parallel paste_selection (TIOCL_PASTESEL)
      and set_selection_user (TIOCL_SETSEL) invocations. One uses sel_buffer,
      while the other frees it and reallocates a new one for another
      selection. Add a mutex to close this race.
      
      The mutex takes care properly of sel_buffer and sel_buffer_lth only. The
      other selection global variables (like sel_start, sel_end, and sel_cons)
      are protected only in set_selection_user. The other functions need quite
      some more work to close the races of the variables there. This is going
      to happen later.
      
      This likely fixes (I am unsure as there is no reproducer provided) bug
      206361 too. It was marked as CVE-2020-8648.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Reported-by: syzbot+59997e8d5cbdc486e6f6@syzkaller.appspotmail.com
      References: https://bugzilla.kernel.org/show_bug.cgi?id=206361
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200210081131.23572-2-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07e6124a
    • J
      vt: selection, handle pending signals in paste_selection · 687bff0c
      Jiri Slaby 提交于
      When pasting a selection to a vt, the task is set as INTERRUPTIBLE while
      waiting for a tty to unthrottle. But signals are not handled at all.
      Normally, this is not a problem as tty_ldisc_receive_buf receives all
      the goods and a user has no reason to interrupt the task.
      
      There are two scenarios where this matters:
      1) when the tty is throttled and a signal is sent to the process, it
         spins on a CPU until the tty is unthrottled. schedule() does not
         really echedule, but returns immediately, of course.
      2) when the sel_buffer becomes invalid, KASAN prevents any reads from it
         and the loop simply does not proceed and spins forever (causing the
         tty to throttle, but the code never sleeps, the same as above). This
         sometimes happens as there is a race in the sel_buffer handling code.
      
      So add signal handling to this ioctl (TIOCL_PASTESEL) and return -EINTR
      in case a signal is pending.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200210081131.23572-1-jslaby@suse.czSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      687bff0c
  14. 13 2月, 2020 1 次提交
    • E
      vt: vt_ioctl: fix race in VT_RESIZEX · 6cd1ed50
      Eric Dumazet 提交于
      We need to make sure vc_cons[i].d is not NULL after grabbing
      console_lock(), or risk a crash.
      
      general protection fault, probably for non-canonical address 0xdffffc0000000068: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x0000000000000340-0x0000000000000347]
      CPU: 1 PID: 19462 Comm: syz-executor.5 Not tainted 5.5.0-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:vt_ioctl+0x1f96/0x26d0 drivers/tty/vt/vt_ioctl.c:883
      Code: 74 41 e8 bd a6 84 fd 48 89 d8 48 c1 e8 03 42 80 3c 28 00 0f 85 e4 04 00 00 48 8b 03 48 8d b8 40 03 00 00 48 89 fa 48 c1 ea 03 <42> 0f b6 14 2a 84 d2 74 09 80 fa 03 0f 8e b1 05 00 00 44 89 b8 40
      RSP: 0018:ffffc900086d7bb0 EFLAGS: 00010202
      RAX: 0000000000000000 RBX: ffffffff8c34ee88 RCX: ffffc9001415c000
      RDX: 0000000000000068 RSI: ffffffff83f0e6e3 RDI: 0000000000000340
      RBP: ffffc900086d7cd0 R08: ffff888054ce0100 R09: fffffbfff16a2f6d
      R10: ffff888054ce0998 R11: ffff888054ce0100 R12: 000000000000001d
      R13: dffffc0000000000 R14: 1ffff920010daf79 R15: 000000000000ff7f
      FS:  00007f7d13c12700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffd477e3c38 CR3: 0000000095d0a000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660
       vfs_ioctl fs/ioctl.c:47 [inline]
       ksys_ioctl+0x123/0x180 fs/ioctl.c:763
       __do_sys_ioctl fs/ioctl.c:772 [inline]
       __se_sys_ioctl fs/ioctl.c:770 [inline]
       __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:770
       do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x45b399
      Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f7d13c11c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 00007f7d13c126d4 RCX: 000000000045b399
      RDX: 0000000020000080 RSI: 000000000000560a RDI: 0000000000000003
      RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 0000000000000666 R14: 00000000004c7f04 R15: 000000000075bf2c
      Modules linked in:
      ---[ end trace 80970faf7a67eb77 ]---
      RIP: 0010:vt_ioctl+0x1f96/0x26d0 drivers/tty/vt/vt_ioctl.c:883
      Code: 74 41 e8 bd a6 84 fd 48 89 d8 48 c1 e8 03 42 80 3c 28 00 0f 85 e4 04 00 00 48 8b 03 48 8d b8 40 03 00 00 48 89 fa 48 c1 ea 03 <42> 0f b6 14 2a 84 d2 74 09 80 fa 03 0f 8e b1 05 00 00 44 89 b8 40
      RSP: 0018:ffffc900086d7bb0 EFLAGS: 00010202
      RAX: 0000000000000000 RBX: ffffffff8c34ee88 RCX: ffffc9001415c000
      RDX: 0000000000000068 RSI: ffffffff83f0e6e3 RDI: 0000000000000340
      RBP: ffffc900086d7cd0 R08: ffff888054ce0100 R09: fffffbfff16a2f6d
      R10: ffff888054ce0998 R11: ffff888054ce0100 R12: 000000000000001d
      R13: dffffc0000000000 R14: 1ffff920010daf79 R15: 000000000000ff7f
      FS:  00007f7d13c12700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007ffd477e3c38 CR3: 0000000095d0a000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: stable <stable@vger.kernel.org>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Link: https://lore.kernel.org/r/20200210190721.200418-1-edumazet@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6cd1ed50
  15. 11 2月, 2020 1 次提交
  16. 04 2月, 2020 1 次提交
    • M
      kbuild: rename hostprogs-y/always to hostprogs/always-y · 5f2fb52f
      Masahiro Yamada 提交于
      In old days, the "host-progs" syntax was used for specifying host
      programs. It was renamed to the current "hostprogs-y" in 2004.
      
      It is typically useful in scripts/Makefile because it allows Kbuild to
      selectively compile host programs based on the kernel configuration.
      
      This commit renames like follows:
      
        always       ->  always-y
        hostprogs-y  ->  hostprogs
      
      So, scripts/Makefile will look like this:
      
        always-$(CONFIG_BUILD_BIN2C) += ...
        always-$(CONFIG_KALLSYMS)    += ...
            ...
        hostprogs := $(always-y) $(always-m)
      
      I think this makes more sense because a host program is always a host
      program, irrespective of the kernel configuration. We want to specify
      which ones to compile by CONFIG options, so always-y will be handier.
      
      The "always", "hostprogs-y", "hostprogs-m" will be kept for backward
      compatibility for a while.
      Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      5f2fb52f
  17. 14 1月, 2020 1 次提交