1. 31 8月, 2016 3 次提交
  2. 04 8月, 2016 1 次提交
    • M
      tree-wide: replace config_enabled() with IS_ENABLED() · 97f2645f
      Masahiro Yamada 提交于
      The use of config_enabled() against config options is ambiguous.  In
      practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the
      author might have used it for the meaning of IS_ENABLED().  Using
      IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc.  makes the intention
      clearer.
      
      This commit replaces config_enabled() with IS_ENABLED() where possible.
      This commit is only touching bool config options.
      
      I noticed two cases where config_enabled() is used against a tristate
      option:
      
       - config_enabled(CONFIG_HWMON)
        [ drivers/net/wireless/ath/ath10k/thermal.c ]
      
       - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
        [ drivers/gpu/drm/gma500/opregion.c ]
      
      I did not touch them because they should be converted to IS_BUILTIN()
      in order to keep the logic, but I was not sure it was the authors'
      intention.
      
      Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Stas Sergeev <stsp@list.ru>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: "Dmitry V. Levin" <ldv@altlinux.org>
      Cc: yu-cheng yu <yu-cheng.yu@intel.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Nikolay Martynov <mar.kolya@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Rafal Milecki <zajec5@gmail.com>
      Cc: James Cowgill <James.Cowgill@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Alex Smith <alex.smith@imgtec.com>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Tony Wu <tung7970@gmail.com>
      Cc: Huaitong Han <huaitong.han@intel.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andrea Gelmini <andrea.gelmini@gelma.net>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Rabin Vincent <rabin@rab.in>
      Cc: "Maciej W. Rozycki" <macro@imgtec.com>
      Cc: David Daney <david.daney@cavium.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      97f2645f
  3. 28 7月, 2016 1 次提交
  4. 27 7月, 2016 3 次提交
  5. 21 7月, 2016 2 次提交
  6. 07 7月, 2016 2 次提交
  7. 06 7月, 2016 1 次提交
  8. 27 6月, 2016 3 次提交
    • C
      devpts: fix null pointer dereference on failed memory allocation · 5353ed8d
      Colin Ian King 提交于
      An ENOMEM when creating a pair tty in tty_ldisc_setup causes a null
      pointer dereference in devpts_kill_index because tty->link->driver_data
      is NULL.  The oops was triggered with the pty stressor in stress-ng when
      in a low memory condition.
      
      tty_init_dev tries to clean up a tty_ldisc_setup ENOMEM error by calling
      release_tty, however, this ultimately tries to clean up the NULL pair'd
      tty in pty_unix98_remove, triggering the Oops.
      
      Add check to pty_unix98_remove to only clean up fsi if it is not NULL.
      
      Ooops:
      
      [   23.020961] Oops: 0000 [#1] SMP
      [   23.020976] Modules linked in: ppdev snd_hda_codec_generic snd_hda_intel snd_hda_codec parport_pc snd_hda_core snd_hwdep parport snd_pcm input_leds joydev snd_timer serio_raw snd soundcore i2c_piix4 mac_hid ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel qxl aes_x86_64 ttm lrw gf128mul glue_helper ablk_helper drm_kms_helper cryptd syscopyarea sysfillrect psmouse sysimgblt floppy fb_sys_fops drm pata_acpi jitterentropy_rng drbg ansi_cprng
      [   23.020978] CPU: 0 PID: 1452 Comm: stress-ng-pty Not tainted 4.7.0-rc4+ #2
      [   23.020978] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      [   23.020979] task: ffff88007ba30000 ti: ffff880078ea8000 task.ti: ffff880078ea8000
      [   23.020981] RIP: 0010:[<ffffffff813f11ff>]  [<ffffffff813f11ff>] ida_remove+0x1f/0x120
      [   23.020981] RSP: 0018:ffff880078eabb60  EFLAGS: 00010a03
      [   23.020982] RAX: 4444444444444567 RBX: 0000000000000000 RCX: 000000000000001f
      [   23.020982] RDX: 000000000000014c RSI: 000000000000026f RDI: 0000000000000000
      [   23.020982] RBP: ffff880078eabb70 R08: 0000000000000004 R09: 0000000000000036
      [   23.020983] R10: 000000000000026f R11: 0000000000000000 R12: 000000000000026f
      [   23.020983] R13: 000000000000026f R14: ffff88007c944b40 R15: 000000000000026f
      [   23.020984] FS:  00007f9a2f3cc700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
      [   23.020984] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   23.020985] CR2: 0000000000000010 CR3: 000000006c81b000 CR4: 00000000001406f0
      [   23.020988] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   23.020988] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   23.020988] Stack:
      [   23.020989]  0000000000000000 000000000000026f ffff880078eabb90 ffffffff812a5a99
      [   23.020990]  0000000000000000 00000000fffffff4 ffff880078eabba8 ffffffff814f9cbe
      [   23.020991]  ffff88007965c800 ffff880078eabbc8 ffffffff814eef43 fffffffffffffff4
      [   23.020991] Call Trace:
      [   23.021000]  [<ffffffff812a5a99>] devpts_kill_index+0x29/0x50
      [   23.021002]  [<ffffffff814f9cbe>] pty_unix98_remove+0x2e/0x50
      [   23.021006]  [<ffffffff814eef43>] release_tty+0xb3/0x1b0
      [   23.021007]  [<ffffffff814f18d4>] tty_init_dev+0xd4/0x1c0
      [   23.021011]  [<ffffffff814f9fae>] ptmx_open+0xae/0x190
      [   23.021013]  [<ffffffff812254ef>] chrdev_open+0xbf/0x1b0
      [   23.021015]  [<ffffffff8121d973>] do_dentry_open+0x203/0x310
      [   23.021016]  [<ffffffff81225430>] ? cdev_put+0x30/0x30
      [   23.021017]  [<ffffffff8121ee44>] vfs_open+0x54/0x80
      [   23.021018]  [<ffffffff8122b8fc>] ? may_open+0x8c/0x100
      [   23.021019]  [<ffffffff8122f26b>] path_openat+0x2eb/0x1440
      [   23.021020]  [<ffffffff81230534>] ? putname+0x54/0x60
      [   23.021022]  [<ffffffff814f6f97>] ? n_tty_ioctl_helper+0x27/0x100
      [   23.021023]  [<ffffffff81231651>] do_filp_open+0x91/0x100
      [   23.021024]  [<ffffffff81230596>] ? getname_flags+0x56/0x1f0
      [   23.021026]  [<ffffffff8123fc66>] ? __alloc_fd+0x46/0x190
      [   23.021027]  [<ffffffff8121f1e4>] do_sys_open+0x124/0x210
      [   23.021028]  [<ffffffff8121f2ee>] SyS_open+0x1e/0x20
      [   23.021035]  [<ffffffff81845576>] entry_SYSCALL_64_fastpath+0x1e/0xa8
      [   23.021044] Code: 63 28 45 31 e4 eb dd 0f 1f 44 00 00 55 4c 63 d6 48 ba 89 88 88 88 88 88 88 88 4c 89 d0 b9 1f 00 00 00 48 f7 e2 48 89 e5 41 54 53 <8b> 47 10 48 89 fb 8d 3c c5 00 00 00 00 48 c1 ea 09 b8 01 00 00
      [   23.021045] RIP  [<ffffffff813f11ff>] ida_remove+0x1f/0x120
      [   23.021045]  RSP <ffff880078eabb60>
      [   23.021046] CR2: 0000000000000010
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5353ed8d
    • N
      tty/serial: atmel: enforce tasklet init and termination sequences · 98f2082c
      Nicolas Ferre 提交于
      As some race conditions are identified in the termination process of tasklets,
      enforce the atmel_shutdown() sequence. This way we make sure that no new
      tasklets or software timer are scheduled during shutdown process.
      
      An atomic flag is positioned to give this information throughout the code.
      
      We also remove tasklet_disable() calls that were leading to deadlocks while
      stopping the driver. A simpler init/kill sequence is used.
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      98f2082c
    • G
      serial: sh-sci: Stop transfers in sci_shutdown() · 5fd2b6ee
      Geert Uytterhoeven 提交于
      Make sure the transmitter and receiver are stopped when shutting down
      the port, and related interrupts are disabled.
      
      Without this:
        - New input data may be received into the RX FIFO, possibly
          triggering a new RX DMA completion,
        - Transfers will still be enabled on a subsequent startup of the UART,
          before the UART's FIFOs have been reset, causing reading of stale
          data.
      
      Inspired by a patch in the BSP by Koji Matsuoka
      <koji.matsuoka.xm@renesas.com>.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5fd2b6ee
  9. 26 6月, 2016 24 次提交