August 2018 - Linux-stable-mirror

by Jeff

We would like to check if your photos need editing. We can do it for you. Our image editing is for web store photos, jewelries images and beauty and portrait photos etc. It is including cut out and clipping path , and also retouching if it is needed. We can do test on your photos. Just send us a photo we will start to work on it, Thanks, Jeff Allen

6 years, 4 months

1
0
0 0

KASAN errors from unwind_frame

by Sodagudi Prasad

Hi All, I have observed following KASAN error with 4.14.56 kernel. Can you please copy change-[1](kasan: add no_sanitize attribute for clang builds) into stable kernels? [1] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/i… ================================================================== BUG: KASAN: out-of-bounds in __read_once_size_nocheck include/linux/compiler.h:196 [inline] BUG: KASAN: out-of-bounds in unwind_frame+0xc4/0x324 arch/arm64/kernel/stacktrace.c:56 Read of size 8 at addr ffffffe3123ff4b0 by task poc/15233 CPU: 7 PID: 15233 Comm: poc Tainted: G S W O 4.14.56+ #3 Hardware name: Qualcomm Technologies, Inc. Call trace: dump_backtrace+0x0/0x388 show_stack+0x24/0x30 __dump_stack+0x24/0x2c dump_stack+0x8c/0xd0 print_address_description+0x74/0x234 kasan_report+0x240/0x264 __asan_report_load8_noabort+0x2c/0x38 unwind_frame+0xc4/0x324 walk_stackframe+0x44/0x6c __save_stack_trace+0x250/0x444 save_stack_trace_tsk+0x2c/0x38 proc_pid_stack+0x134/0x268 proc_single_show+0xdc/0x130 traverse+0x244/0x5b0 seq_lseek+0x10c/0x27c vfs_llseek+0xb4/0xe4 SyS_lseek+0x54/0xa0 el0_svc_naked+0x34/0x38 The buggy address belongs to the page: page:ffffffbf8c48ffc0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x0() raw: 0000000000000000 0000000000000000 0000000000000000 00000000ffffffff raw: 0000000000000000 dead000000000200 0000000000000000 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not active (free page?) Memory state around the buggy address: ffffffe3123ff380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffe3123ff400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffffffe3123ff480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ffffffe3123ff500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffe3123ff580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== -Thanks, Prasad -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project

6 years, 4 months

2
1
0 0

[PATCH] bcache: fix 0day error of setting writeback_rate by sysfs interface

by Coly Li

Commit ea8c5356d390 ("bcache: set max writeback rate when I/O request is idle") changes struct bch_ratelimit member rate from uint32_t to atomic_long_t and uses atomic_long_set() in drivers/md/bcache/sysfs.c to set new writeback rate, after the input is converted from memory buf to long int by sysfs_strtoul_clamp(). The above change has a problem because there is an implicit return inside sysfs_strtoul_clamp() so the following atomic_long_set() won't be called. This error is detected by 0day system with following snipped smatch warnings: drivers/md/bcache/sysfs.c:271 __cached_dev_store() error: uninitialized symbol 'v'. 270 sysfs_strtoul_clamp(writeback_rate, v, 1, INT_MAX); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @271 atomic_long_set(&dc->writeback_rate.rate, v); This patch fixes the above error by using strtoul_safe_clamp() to convert the input buffer into a long int type result. Fixes: Commit ea8c5356d390 ("bcache: set max writeback rate when I/O request is idle") Signed-off-by: Coly Li <colyli(a)suse.de> Cc: stable(a)vger.kernel.org #4.16+ Cc: Kai Krakow <kai(a)kaishome.de> Cc: Stefan Priebe <s.priebe(a)profihost.ag> --- drivers/md/bcache/sysfs.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c index 543b06408321..150cf4f4cf74 100644 --- a/drivers/md/bcache/sysfs.c +++ b/drivers/md/bcache/sysfs.c @@ -267,10 +267,17 @@ STORE(__cached_dev) sysfs_strtoul_clamp(writeback_percent, dc->writeback_percent, 0, 40); if (attr == &sysfs_writeback_rate) { - int v; + ssize_t ret; + long int v = atomic_long_read(&dc->writeback_rate.rate); + + ret = strtoul_safe_clamp(buf, v, 1, INT_MAX); - sysfs_strtoul_clamp(writeback_rate, v, 1, INT_MAX); - atomic_long_set(&dc->writeback_rate.rate, v); + if (!ret) { + atomic_long_set(&dc->writeback_rate.rate, v); + ret = size; + } + + return ret; } sysfs_strtoul_clamp(writeback_rate_update_seconds, -- 2.18.0

6 years, 4 months

2
2
0 0

[patch 4/4] zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature

by akpm＠linux-foundation.org

From: Minchan Kim <minchan(a)kernel.org> Subject: zram: remove BD_CAP_SYNCHRONOUS_IO with writeback feature If zram supports writeback feature, it's no longer a BD_CAP_SYNCHRONOUS_IO device beause zram does asynchronous IO operations for incompressible pages. Do not pretend to be synchronous IO device. It makes the system very sluggish due to waiting for IO completion from upper layers. Furthermore, it causes a user-after-free problem because swap thinks the opearion is done when the IO functions returns so it can free the page (e.g., lock_page_or_retry and goto out_release in do_swap_page) but in fact, IO is asynchronous so the driver could access a just freed page afterward. This patch fixes the problem. BUG: Bad page state in process qemu-system-x86 pfn:3dfab21 page:ffffdfb137eac840 count:0 mapcount:0 mapping:0000000000000000 index:0x1 flags: 0x17fffc000000008(uptodate) raw: 017fffc000000008 dead000000000100 dead000000000200 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set bad because of flags: 0x8(uptodate) Modules linked in: lz4 lz4_compress zram zsmalloc intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel bin fmt_misc pcbc aesni_intel aes_x86_64 crypto_simd cryptd iTCO_wdt glue_helper iTCO_vendor_support intel_cstate lpc_ich mei_me intel_uncore intel_rapl_perf pcspkr joydev sg mfd_core ioatdma mei wmi evdev ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter acpi_pad button ip_tables x_tables autofs4 ext4 crc32c_generic crc16 mbcache jbd2 fscrypto hid_generic usbhid hid sd_mod xhci_pci ehci_pci ahci libahci xhci_hcd ehci_hcd libata igb i2c_algo_bit crc32c_intel scsi_mod i2c_i8 01 dca usbcore CPU: 4 PID: 1039 Comm: qemu-system-x86 Tainted: G B 4.18.0-rc5+ #1 Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0b 05/02/2017 Call Trace: dump_stack+0x5c/0x7b bad_page+0xba/0x120 get_page_from_freelist+0x1016/0x1250 __alloc_pages_nodemask+0xfa/0x250 alloc_pages_vma+0x7c/0x1c0 do_swap_page+0x347/0x920 ? __update_load_avg_se.isra.38+0x1eb/0x1f0 ? cpumask_next_wrap+0x3d/0x60 __handle_mm_fault+0x7b4/0x1110 ? update_load_avg+0x5ea/0x720 handle_mm_fault+0xfc/0x1f0 __get_user_pages+0x12f/0x690 get_user_pages_unlocked+0x148/0x1f0 __gfn_to_pfn_memslot+0xff/0x3c0 [kvm] try_async_pf+0x87/0x230 [kvm] tdp_page_fault+0x132/0x290 [kvm] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] kvm_mmu_page_fault+0x74/0x570 [kvm] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] ? vmexit_fill_RSB+0x18/0x30 [kvm_intel] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel] ? vmx_vcpu_run+0x375/0x620 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x9b3/0x1990 [kvm] ? __update_load_avg_se.isra.38+0x1eb/0x1f0 ? kvm_vcpu_ioctl+0x388/0x5d0 [kvm] kvm_vcpu_ioctl+0x388/0x5d0 [kvm] ? __switch_to+0x395/0x450 ? __switch_to+0x395/0x450 do_vfs_ioctl+0xa2/0x630 ? __schedule+0x3fd/0x890 ksys_ioctl+0x70/0x80 ? exit_to_usermode_loop+0xca/0xf0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fb30361add7 Code: 00 00 00 48 8b 05 c1 80 2b 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 91 80 2b 00 f7 d8 64 89 01 48 RSP: 002b:00007fb2e97f98b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007fb30361add7 RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000015 RBP: 00005652b984e0f0 R08: 00005652b7d513d0 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fb308c66000 R14: 0000000000000000 R15: 00005652b984e0f0 Link: https://lore.kernel.org/lkml/0516ae2d-b0fd-92c5-aa92-112ba7bd32fc@contabo.d… Link: http://lkml.kernel.org/r/20180802051112.86174-1-minchan@kernel.org [minchan(a)kernel.org: fix changelog, add comment] Link: https://lore.kernel.org/lkml/0516ae2d-b0fd-92c5-aa92-112ba7bd32fc@contabo.d… Link: http://lkml.kernel.org/r/20180802051112.86174-1-minchan@kernel.org Link: http://lkml.kernel.org/r/20180805233722.217347-1-minchan@kernel.org [akpm(a)linux-foundation.org: coding-style fixes] Signed-off-by: Minchan Kim <minchan(a)kernel.org> Reported-by: Tino Lehnig <tino.lehnig(a)contabo.de> Tested-by: Tino Lehnig <tino.lehnig(a)contabo.de> Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: <stable(a)vger.kernel.org> [4.15+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/block/zram/zram_drv.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) --- a/drivers/block/zram/zram_drv.c~zram-remove-bd_cap_synchronous_io-with-writeback-feature +++ a/drivers/block/zram/zram_drv.c @@ -298,7 +298,8 @@ static void reset_bdev(struct zram *zram zram->backing_dev = NULL; zram->old_block_size = 0; zram->bdev = NULL; - + zram->disk->queue->backing_dev_info->capabilities |= + BDI_CAP_SYNCHRONOUS_IO; kvfree(zram->bitmap); zram->bitmap = NULL; } @@ -400,6 +401,18 @@ static ssize_t backing_dev_store(struct zram->backing_dev = backing_dev; zram->bitmap = bitmap; zram->nr_pages = nr_pages; + /* + * With writeback feature, zram does asynchronous IO so it's no longer + * synchronous device so let's remove synchronous io flag. Othewise, + * upper layer(e.g., swap) could wait IO completion rather than + * (submit and return), which will cause system sluggish. + * Furthermore, when the IO function returns(e.g., swap_readpage), + * upper layer expects IO was done so it could deallocate the page + * freely but in fact, IO is going on so finally could cause + * use-after-free when the IO is really done. + */ + zram->disk->queue->backing_dev_info->capabilities &= + ~BDI_CAP_SYNCHRONOUS_IO; up_write(&zram->init_lock); pr_info("setup backing device %s\n", file_name); _

6 years, 4 months

1
0
0 0

[folded-merged] zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2 has been removed from the -mm tree. Its filename was zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2.patch This patch was dropped because it was folded into zram-remove-bd_cap_synchronous_io-with-writeback-feature.patch ------------------------------------------------------ From: Minchan Kim <minchan(a)kernel.org> Subject: zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2 - description correction - Andrew - add comment about removing BDI_CAP_SYNCHRONOUS_IO Link: https://lore.kernel.org/lkml/0516ae2d-b0fd-92c5-aa92-112ba7bd32fc@contabo.d… Link: http://lkml.kernel.org/r/20180802051112.86174-1-minchan@kernel.org Link: http://lkml.kernel.org/r/20180805233722.217347-1-minchan@kernel.org Signed-off-by: Minchan Kim <minchan(a)kernel.org> Reported-by: Tino Lehnig <tino.lehnig(a)contabo.de> Tested-by: Tino Lehnig <tino.lehnig(a)contabo.de> Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: <stable(a)vger.kernel.org> [4.15+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN drivers/block/zram/zram_drv.c~zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2 drivers/block/zram/zram_drv.c --- a/drivers/block/zram/zram_drv.c~zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2 +++ a/drivers/block/zram/zram_drv.c @@ -401,6 +401,16 @@ static ssize_t backing_dev_store(struct zram->backing_dev = backing_dev; zram->bitmap = bitmap; zram->nr_pages = nr_pages; + /* + * With writeback feature, zram does asynchronous IO so it's no longer + * synchronous device so let's remove synchronous io flag. Othewise, + * upper layer(e.g., swap) could wait IO completion rather than + * (submit and return), which will cause system sluggish. + * Furthermore, when the IO function returns(e.g., swap_readpage), + * upper layer expects IO was done so it could deallocate the page + * freely but in fact, IO is going on so finally could cause + * use-after-free when the IO is really done. + */ zram->disk->queue->backing_dev_info->capabilities &= ~BDI_CAP_SYNCHRONOUS_IO; up_write(&zram->init_lock); _ Patches currently in -mm which might be from minchan(a)kernel.org are zram-remove-bd_cap_synchronous_io-with-writeback-feature.patch

6 years, 4 months

1
0
0 0

+ reiserfs-fix-broken-xattr-handling-heap-corruption-bad-retval.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: reiserfs: fix broken xattr handling (heap corruption, bad retval) has been added to the -mm tree. Its filename is reiserfs-fix-broken-xattr-handling-heap-corruption-bad-retval.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/reiserfs-fix-broken-xattr-handling… and later at http://ozlabs.org/~akpm/mmotm/broken-out/reiserfs-fix-broken-xattr-handling… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Jann Horn <jannh(a)google.com> Subject: reiserfs: fix broken xattr handling (heap corruption, bad retval) This fixes the following issues: - When a buffer size is supplied to reiserfs_listxattr() such that each individual name fits, but the concatenation of all names doesn't fit, reiserfs_listxattr() overflows the supplied buffer. This leads to a kernel heap overflow (verified using KASAN) followed by an out-of-bounds usercopy and is therefore a security bug. - When a buffer size is supplied to reiserfs_listxattr() such that a name doesn't fit, -ERANGE should be returned. But reiserfs instead just truncates the list of names; I have verified that if the only xattr on a file has a longer name than the supplied buffer length, listxattr() incorrectly returns zero. With my patch applied, -ERANGE is returned in both cases and the memory corruption doesn't happen anymore. Credit for making me clean this code up a bit goes to Al Viro, who pointed out that the ->actor calling convention is suboptimal and should be changed. Link: http://lkml.kernel.org/r/20180802151539.5373-1-jannh@google.com Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers") Signed-off-by: Jann Horn <jannh(a)google.com> Cc: Jeff Mahoney <jeffm(a)suse.com> Cc: Eric Biggers <ebiggers(a)google.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/reiserfs/xattr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/fs/reiserfs/xattr.c~reiserfs-fix-broken-xattr-handling-heap-corruption-bad-retval +++ a/fs/reiserfs/xattr.c @@ -792,8 +792,10 @@ static int listxattr_filler(struct dir_c return 0; size = namelen + 1; if (b->buf) { - if (size > b->size) + if (b->pos + size > b->size) { + b->pos = -ERANGE; return -ERANGE; + } memcpy(b->buf + b->pos, name, namelen); b->buf[b->pos + namelen] = 0; } _ Patches currently in -mm which might be from jannh(a)google.com are reiserfs-fix-broken-xattr-handling-heap-corruption-bad-retval.patch fork-dont-copy-inconsistent-signal-handler-state-to-child.patch

6 years, 4 months

1
0
0 0

[PATCH v5 10/13] drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

by Lyude Paul

It's true we can't resume the device from poll workers in nouveau_connector_detect(). We can however, prevent the autosuspend timer from elapsing immediately if it hasn't already without risking any sort of deadlock with the runtime suspend/resume operations. So do that instead of entirely avoiding grabbing a power reference. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 2a45b4c2ceb0..010d6db14cba 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -572,12 +572,16 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) nv_connector->edid = NULL; } - /* Outputs are only polled while runtime active, so acquiring a - * runtime PM ref here is unnecessary (and would deadlock upon - * runtime suspend because it waits for polling to finish). + /* Outputs are only polled while runtime active, so resuming the + * device here is unnecessary (and would deadlock upon runtime suspend + * because it waits for polling to finish). We do however, want to + * prevent the autosuspend timer from elapsing during this operation + * if possible. */ - if (!drm_kms_helper_is_poll_worker()) { - ret = pm_runtime_get_sync(connector->dev->dev); + if (drm_kms_helper_is_poll_worker()) { + pm_runtime_get_noresume(dev->dev); + } else { + ret = pm_runtime_get_sync(dev->dev); if (ret < 0 && ret != -EACCES) return conn_status; } @@ -655,10 +659,8 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) out: - if (!drm_kms_helper_is_poll_worker()) { - pm_runtime_mark_last_busy(connector->dev->dev); - pm_runtime_put_autosuspend(connector->dev->dev); - } + pm_runtime_mark_last_busy(dev->dev); + pm_runtime_put_autosuspend(dev->dev); return conn_status; } -- 2.17.1

6 years, 4 months

2
1
0 0

[PATCH v5 08/13] drm/nouveau: Don't ignore nouveau_do_suspend() ret value

by Lyude Paul

Otherwise, how will we roll everything back? Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index db56e9b6b6af..f79b435368ec 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -842,6 +842,9 @@ nouveau_pmops_runtime_suspend(struct device *dev) } ret = nouveau_do_suspend(drm_dev, true); + if (ret) + return ret; + nouveau_switcheroo_optimus_dsm(); pci_save_state(pdev); pci_disable_device(pdev); -- 2.17.1

6 years, 4 months

2
1
0 0

[PATCH v5 07/13] drm/nouveau: Add missing unroll functions in nouveau_do_suspend()

by Lyude Paul

Currently, it appears that nouveau_do_suspend() forgets to roll back suspending fbcon and suspending the device LEDs. We also currently skip the entire rollback process if nouveau_display_suspend() fails. So, fix that. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 5ea8fe992484..db56e9b6b6af 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -674,10 +674,11 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime) if (dev->mode_config.num_crtc) { NV_DEBUG(drm, "suspending console...\n"); nouveau_fbcon_set_suspend(dev, 1); + NV_DEBUG(drm, "suspending display...\n"); ret = nouveau_display_suspend(dev, runtime); if (ret) - return ret; + goto fail_fbcon; } NV_DEBUG(drm, "evicting buffers...\n"); @@ -719,7 +720,14 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime) if (dev->mode_config.num_crtc) { NV_DEBUG(drm, "resuming display...\n"); nouveau_display_resume(dev, runtime); + +fail_fbcon: + NV_DEBUG(drm, "resuming console...\n"); + nouveau_fbcon_set_suspend(dev, 0); } + + nouveau_led_resume(dev); + return ret; } -- 2.17.1

6 years, 4 months

2
1
0 0

[PATCH v5 06/13] drm/nouveau: Call optimus_dsm functions after nouveau_do_suspend()

by Lyude Paul

It's not necessary to call these before we call nouveau_do_suspend(). Ideally; we shouldn't have to call this at all here, but getting that to work will take a bit more effort. So for the time being, just move this call after nouveau_do_suspend() to allow us to easily be able to abort the runtime suspend process in nouveau_do_suspend() Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 04f704b77a3c..5ea8fe992484 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -833,8 +833,8 @@ nouveau_pmops_runtime_suspend(struct device *dev) return -EBUSY; } - nouveau_switcheroo_optimus_dsm(); ret = nouveau_do_suspend(drm_dev, true); + nouveau_switcheroo_optimus_dsm(); pci_save_state(pdev); pci_disable_device(pdev); pci_ignore_hotplug(pdev); -- 2.17.1

6 years, 4 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2018