- Linux-stable-mirror - lists.linaro.org

[PATCH v3 1/2] powerpc/fadump: handle crash memory ranges array index overflow

by Hari Bathini

Crash memory ranges is an array of memory ranges of the crashing kernel to be exported as a dump via /proc/vmcore file. The size of the array is set based on INIT_MEMBLOCK_REGIONS, which works alright in most cases where memblock memory regions count is less than INIT_MEMBLOCK_REGIONS value. But this count can grow beyond INIT_MEMBLOCK_REGIONS value since commit 142b45a72e22 ("memblock: Add array resizing support"). On large memory systems with a few DLPAR operations, the memblock memory regions count could be larger than INIT_MEMBLOCK_REGIONS value. On such systems, registering fadump results in crash or other system failures like below: task: c00007f39a290010 ti: c00000000b738000 task.ti: c00000000b738000 NIP: c000000000047df4 LR: c0000000000f9e58 CTR: c00000000010f180 REGS: c00000000b73b570 TRAP: 0300 Tainted: G L X (4.4.140+) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 22004484 XER: 20000000 CFAR: c000000000008500 DAR: 000007a450000000 DSISR: 40000000 SOFTE: 0 GPR00: c0000000000f9e58 c00000000b73b7f0 c000000000f09a00 000000000000001a GPR04: c00007f3bf774c90 0000000000000004 c000000000eb9a00 0000000000000800 GPR08: 0000000000000804 000007a450000000 c000000000fa9a00 c00007ffb169ca20 GPR12: 0000000022004482 c00000000fa12c00 c00007f3a0ea97a8 0000000000000000 GPR16: c00007f3a0ea9a50 c00000000b73bd60 0000000000000118 000000000001fe80 GPR20: 0000000000000118 0000000000000000 c000000000b8c980 00000000000000d0 GPR24: 000007ffb0b10000 c00007ffb169c980 0000000000000000 c000000000b8c980 GPR28: 0000000000000004 c00007ffb169c980 000000000000001a c00007ffb169c980 NIP [c000000000047df4] smp_send_reschedule+0x24/0x80 LR [c0000000000f9e58] resched_curr+0x138/0x160 Call Trace: [c00000000b73b7f0] [c0000000000f9e58] resched_curr+0x138/0x160 (unreliable) [c00000000b73b820] [c0000000000fb538] check_preempt_curr+0xc8/0xf0 [c00000000b73b850] [c0000000000fb598] ttwu_do_wakeup+0x38/0x150 [c00000000b73b890] [c0000000000fc9c4] try_to_wake_up+0x224/0x4d0 [c00000000b73b900] [c00000000011ef34] __wake_up_common+0x94/0x100 [c00000000b73b960] [c00000000034a78c] ep_poll_callback+0xac/0x1c0 [c00000000b73b9b0] [c00000000011ef34] __wake_up_common+0x94/0x100 [c00000000b73ba10] [c00000000011f810] __wake_up_sync_key+0x70/0xa0 [c00000000b73ba60] [c00000000067c3e8] sock_def_readable+0x58/0xa0 [c00000000b73ba90] [c0000000007848ac] unix_stream_sendmsg+0x2dc/0x4c0 [c00000000b73bb70] [c000000000675a38] sock_sendmsg+0x68/0xa0 [c00000000b73bba0] [c00000000067673c] ___sys_sendmsg+0x2cc/0x2e0 [c00000000b73bd30] [c000000000677dbc] __sys_sendmsg+0x5c/0xc0 [c00000000b73bdd0] [c0000000006789bc] SyS_socketcall+0x36c/0x3f0 [c00000000b73be30] [c000000000009488] system_call+0x3c/0x100 Instruction dump: 4e800020 60000000 60420000 3c4c00ec 38421c30 7c0802a6 f8010010 60000000 3d42000a e92ab420 2fa90000 4dde0020 <e9290000> 2fa90000 419e0044 7c0802a6 ---[ end trace a6d1dd4bab5f8253 ]--- as array index overflow is not checked for while setting up crash memory ranges causing memory corruption. To resolve this issue, dynamically allocate memory for crash memory ranges and resize it incrementally, in units of pagesize, on hitting array size limit. Fixes: 2df173d9e85d ("fadump: Initialize elfcore header and add PT_LOAD program headers.") Cc: stable(a)vger.kernel.org Cc: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com> --- Changes in v3: * Included <linux/slab.h> for krelloc() arch/powerpc/include/asm/fadump.h | 4 +- arch/powerpc/kernel/fadump.c | 92 +++++++++++++++++++++++++++++++------ 2 files changed, 80 insertions(+), 16 deletions(-) diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h index 5a23010..3abc738 100644 --- a/arch/powerpc/include/asm/fadump.h +++ b/arch/powerpc/include/asm/fadump.h @@ -195,8 +195,8 @@ struct fadump_crash_info_header { struct cpumask online_mask; }; -/* Crash memory ranges */ -#define INIT_CRASHMEM_RANGES (INIT_MEMBLOCK_REGIONS + 2) +/* Crash memory ranges size unit (pagesize) */ +#define CRASHMEM_RANGES_ALLOC_SIZE PAGE_SIZE struct fad_crash_memory_ranges { unsigned long long base; diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c index 07e8396..9f80a78 100644 --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -34,6 +34,7 @@ #include <linux/crash_dump.h> #include <linux/kobject.h> #include <linux/sysfs.h> +#include <linux/slab.h> #include <asm/debugfs.h> #include <asm/page.h> @@ -47,8 +48,10 @@ static struct fadump_mem_struct fdm; static const struct fadump_mem_struct *fdm_active; static DEFINE_MUTEX(fadump_mutex); -struct fad_crash_memory_ranges crash_memory_ranges[INIT_CRASHMEM_RANGES]; +struct fad_crash_memory_ranges *crash_memory_ranges; +int crash_memory_ranges_size; int crash_mem_ranges; +int max_crash_mem_ranges; /* Scan the Firmware Assisted dump configuration details. */ int __init early_init_dt_scan_fw_dump(unsigned long node, @@ -868,22 +871,67 @@ static int __init process_fadump(const struct fadump_mem_struct *fdm_active) return 0; } -static inline void fadump_add_crash_memory(unsigned long long base, - unsigned long long end) +static void free_crash_memory_ranges(void) +{ + kfree(crash_memory_ranges); + crash_memory_ranges = NULL; + crash_memory_ranges_size = 0; + max_crash_mem_ranges = 0; +} + +/* + * Allocate or reallocate crash memory ranges array in incremental units + * of CRASHMEM_RANGES_ALLOC_SIZE. + */ +static int allocate_crash_memory_ranges(void) +{ + u64 new_size; + struct fad_crash_memory_ranges *new_array; + + new_size = crash_memory_ranges_size + CRASHMEM_RANGES_ALLOC_SIZE; + pr_debug("Allocating %llu bytes of memory for crash memory ranges\n", + new_size); + + new_array = krealloc(crash_memory_ranges, new_size, GFP_KERNEL); + if (new_array == NULL) { + pr_err("Insufficient memory for setting up crash memory ranges\n"); + free_crash_memory_ranges(); + return -ENOMEM; + } + + crash_memory_ranges = new_array; + crash_memory_ranges_size = new_size; + max_crash_mem_ranges = (new_size / + sizeof(struct fad_crash_memory_ranges)); + return 0; +} + +static inline int fadump_add_crash_memory(unsigned long long base, + unsigned long long end) { if (base == end) - return; + return 0; + + if (crash_mem_ranges == max_crash_mem_ranges) { + int ret; + + ret = allocate_crash_memory_ranges(); + if (ret) + return ret; + } pr_debug("crash_memory_range[%d] [%#016llx-%#016llx], %#llx bytes\n", crash_mem_ranges, base, end - 1, (end - base)); crash_memory_ranges[crash_mem_ranges].base = base; crash_memory_ranges[crash_mem_ranges].size = end - base; crash_mem_ranges++; + return 0; } -static void fadump_exclude_reserved_area(unsigned long long start, +static int fadump_exclude_reserved_area(unsigned long long start, unsigned long long end) { + int ret = 0; unsigned long long ra_start, ra_end; ra_start = fw_dump.reserve_dump_area_start; @@ -891,15 +939,20 @@ static void fadump_exclude_reserved_area(unsigned long long start, if ((ra_start < end) && (ra_end > start)) { if ((start < ra_start) && (end > ra_end)) { - fadump_add_crash_memory(start, ra_start); - fadump_add_crash_memory(ra_end, end); + ret = fadump_add_crash_memory(start, ra_start); + if (ret) + return ret; + + ret = fadump_add_crash_memory(ra_end, end); } else if (start < ra_start) { - fadump_add_crash_memory(start, ra_start); + ret = fadump_add_crash_memory(start, ra_start); } else if (ra_end < end) { - fadump_add_crash_memory(ra_end, end); + ret = fadump_add_crash_memory(ra_end, end); } } else - fadump_add_crash_memory(start, end); + ret = fadump_add_crash_memory(start, end); + + return ret; } static int fadump_init_elfcore_header(char *bufp) @@ -939,8 +992,9 @@ static int fadump_init_elfcore_header(char *bufp) * Traverse through memblock structure and setup crash memory ranges. These * ranges will be used create PT_LOAD program headers in elfcore header. */ -static void fadump_setup_crash_memory_ranges(void) +static int fadump_setup_crash_memory_ranges(void) { + int ret; struct memblock_region *reg; unsigned long long start, end; @@ -953,7 +1007,9 @@ static void fadump_setup_crash_memory_ranges(void) * specified during fadump registration. We need to create a separate * program header for this chunk with the correct offset. */ - fadump_add_crash_memory(RMA_START, fw_dump.boot_memory_size); + ret = fadump_add_crash_memory(RMA_START, fw_dump.boot_memory_size); + if (ret) + return ret; for_each_memblock(memory, reg) { start = (unsigned long long)reg->base; @@ -973,8 +1029,12 @@ static void fadump_setup_crash_memory_ranges(void) } /* add this range excluding the reserved dump area. */ - fadump_exclude_reserved_area(start, end); + ret = fadump_exclude_reserved_area(start, end); + if (ret) + return ret; } + + return 0; } /* @@ -1095,6 +1155,7 @@ static unsigned long init_fadump_header(unsigned long addr) static int register_fadump(void) { + int ret; unsigned long addr; void *vaddr; @@ -1105,7 +1166,9 @@ static int register_fadump(void) if (!fw_dump.reserve_dump_area_size) return -ENODEV; - fadump_setup_crash_memory_ranges(); + ret = fadump_setup_crash_memory_ranges(); + if (ret) + return ret; addr = be64_to_cpu(fdm.rmr_region.destination_address) + be64_to_cpu(fdm.rmr_region.source_len); /* Initialize fadump crash info header. */ @@ -1183,6 +1246,7 @@ void fadump_cleanup(void) } else if (fw_dump.dump_registered) { /* Un-register Firmware-assisted dump if it was registered. */ fadump_unregister_dump(&fdm); + free_crash_memory_ranges(); } }

6 years, 11 months

1
0
0 0

AW: Kontakt

by BL Support

Guten Tag Nachdem wir Ihre Internetseite besucht und uns mit dem Angebot vertraut gemacht hatten, trafen wir die Entscheidung, die vorliegende E-Mail zu verfassen. Wir verfügen über Kontakte zu Firmen in Deutschland, die an der Aufnahme der potentiellen Zusammenarbeit mit Ihnen interessiert wären. Mithilfe unserer Tools können Sie Ihre Zielbranche schnell aufsuchen und neue Kunden erreichen. http://www.kontakt-marketing-at.net/ MfG BL-Team.

6 years, 11 months

1
0
0 0

[RESEND] requests for xfs patches inclusion in 4.14.y

by Eduardo Valentin

Greg, Please consider adding the following XFS patches on linux-4.14.y branch to fix NULL pointer dereference errors in lookup_slow() on a NULL inode->i_ops and for a corrupted xfs image after xfs_da_shrink_inode(): ee457001ed6c ("xfs: catch inode allocation state mismatch corruption") afca6c5b2595 ("xfs: validate cached inodes are free when allocated") bb3d48dcf86a ("xfs: don't call xfs_da_shrink_inode with NULL bp") Thanks. -- All the best, Eduardo Valentin

6 years, 11 months

3
4
0 0

Tom Gall <tom.gall@linaro.org>, Alistair Strachan <alistair.strachan@linaro.org>, Greg Kroah-Hartman <gregkh@google.com>, "avid S. Miller" <davem@davemloft.net>, John Stultz <john.stultz@linaro.org>, Thomas Egerer <hakke_007@gmx.de>, Herbert Xu <herbert@gondor.apana.org.au>

by Yongqin Liu

Hi, All Sorry, I am following the instructions in Documentation/networking/netdev-FAQ.txt to send out this mail, if I was wrong or there are more things I need to do, please let me know. After investigated on some failures of the android VtsKernelNetTest module test, I found that without the change of "ipv4+ipv6: Make INET*_ESP select CRYPTO_ECHAINIV", the config of CRYPTO_ECHAINIV will be generated as m by default in the .config file, which needs more module loading process to be done. But with the 4.9 and 4.14 kernels which have the change, CRYPTO_ECHAINIV will be generated as y by default in the .config file. We could set config of CRYPTO_ECHAINIV to y explicitly to generated the correct .config file, but having the change of "ipv4+ipv6: Make INET*_ESP select CRYPTO_ECHAINIV" cherry picked into the 4.4 stable kernel looks more like the right solution. The commit id for that change is 32b6170ca59ccf07d0e394561e54b2cd9726038c, it's already in 4.9 and 4.14 kernels, like here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net… https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net… Could you please help to check if we could have 32b6170ca59ccf07d0e394561e54b2cd9726038c in the 4.4 stable kernel? The patch is here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/net?… Thanks in advance! -- Best Regards, Yongqin Liu

6 years, 11 months

1
0
0 0

[PATCH v4 1/2] block: Introduce blk_exit_queue()

by Bart Van Assche

This patch does not change any functionality. Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Ming Lei <ming.lei(a)redhat.com> Cc: Omar Sandoval <osandov(a)fb.com> Cc: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: Alexandru Moise <00moses.alexander00(a)gmail.com> Cc: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: <stable(a)vger.kernel.org> --- block/blk-core.c | 54 +++++++++++++++++++++++++++--------------------- block/blk.h | 1 + 2 files changed, 31 insertions(+), 24 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index 7c65e297a4f1..5fbfa8484c95 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -719,6 +719,35 @@ void blk_set_queue_dying(struct request_queue *q) } EXPORT_SYMBOL_GPL(blk_set_queue_dying); +/* Unconfigure the I/O scheduler and dissociate from the cgroup controller. */ +void blk_exit_queue(struct request_queue *q) +{ + /* + * Since the I/O scheduler exit code may access cgroup information, + * perform I/O scheduler exit before disassociating from the block + * cgroup controller. + */ + if (q->elevator) { + ioc_clear_queue(q); + elevator_exit(q, q->elevator); + q->elevator = NULL; + } + + /* + * Remove all references to @q from the block cgroup controller before + * restoring @q->queue_lock to avoid that restoring this pointer causes + * e.g. blkcg_print_blkgs() to crash. + */ + blkcg_exit_queue(q); + + /* + * Since the cgroup code may dereference the @q->backing_dev_info + * pointer, only decrease its reference count after having removed the + * association with the block cgroup controller. + */ + bdi_put(q->backing_dev_info); +} + /** * blk_cleanup_queue - shutdown a request queue * @q: request queue to shutdown @@ -788,30 +817,7 @@ void blk_cleanup_queue(struct request_queue *q) */ WARN_ON_ONCE(q->kobj.state_in_sysfs); - /* - * Since the I/O scheduler exit code may access cgroup information, - * perform I/O scheduler exit before disassociating from the block - * cgroup controller. - */ - if (q->elevator) { - ioc_clear_queue(q); - elevator_exit(q, q->elevator); - q->elevator = NULL; - } - - /* - * Remove all references to @q from the block cgroup controller before - * restoring @q->queue_lock to avoid that restoring this pointer causes - * e.g. blkcg_print_blkgs() to crash. - */ - blkcg_exit_queue(q); - - /* - * Since the cgroup code may dereference the @q->backing_dev_info - * pointer, only decrease its reference count after having removed the - * association with the block cgroup controller. - */ - bdi_put(q->backing_dev_info); + blk_exit_queue(q); if (q->mq_ops) blk_mq_free_queue(q); diff --git a/block/blk.h b/block/blk.h index 6adae8f94279..aeb8026f4d7b 100644 --- a/block/blk.h +++ b/block/blk.h @@ -130,6 +130,7 @@ void blk_free_flush_queue(struct blk_flush_queue *q); int blk_init_rl(struct request_list *rl, struct request_queue *q, gfp_t gfp_mask); void blk_exit_rl(struct request_queue *q, struct request_list *rl); +void blk_exit_queue(struct request_queue *q); void blk_rq_bio_prep(struct request_queue *q, struct request *rq, struct bio *bio); void blk_queue_bypass_start(struct request_queue *q); -- 2.18.0

6 years, 11 months

2
1
0 0

[PATCH] PCI: Fix bit definitions for LNKCAP2 register

by Felipe Balbi

Even thhough commit b891b4dc1eed claimed that original bit definitions were wrong, that's not really the case. After verifying PCI Specification Revisions 3.0, 3.1 and 4.0, Link Capabilites 2 Register's bit definitions were always starting from Bit 0. This has been causing issues reporting correct link speeds on sysfs. Fixes: b891b4dc1eed ("PCI: Fix bit definitions of PCI_EXP_LNKCAP2 register") Cc: <stable(a)vger.kernel.org> # v3.8+ Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> --- PCI Spec References: - 4.0 https://members.pcisig.com/wg/PCI-SIG/document/10912?downloadRevision=active - 3.1 https://members.pcisig.com/wg/PCI-SIG/document/download/8257 - 3.0 https://members.pcisig.com/wg/PCI-SIG/document/download/8265 include/uapi/linux/pci_regs.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h index 796d12910791..6ad597b3d082 100644 --- a/include/uapi/linux/pci_regs.h +++ b/include/uapi/linux/pci_regs.h @@ -652,10 +652,10 @@ #define PCI_EXP_DEVSTA2 42 /* Device Status 2 */ #define PCI_CAP_EXP_RC_ENDPOINT_SIZEOF_V2 44 /* v2 endpoints without link end here */ #define PCI_EXP_LNKCAP2 44 /* Link Capabilities 2 */ -#define PCI_EXP_LNKCAP2_SLS_2_5GB 0x00000002 /* Supported Speed 2.5GT/s */ -#define PCI_EXP_LNKCAP2_SLS_5_0GB 0x00000004 /* Supported Speed 5GT/s */ -#define PCI_EXP_LNKCAP2_SLS_8_0GB 0x00000008 /* Supported Speed 8GT/s */ -#define PCI_EXP_LNKCAP2_SLS_16_0GB 0x00000010 /* Supported Speed 16GT/s */ +#define PCI_EXP_LNKCAP2_SLS_2_5GB 0x00000001 /* Supported Speed 2.5GT/s */ +#define PCI_EXP_LNKCAP2_SLS_5_0GB 0x00000002 /* Supported Speed 5GT/s */ +#define PCI_EXP_LNKCAP2_SLS_8_0GB 0x00000004 /* Supported Speed 8GT/s */ +#define PCI_EXP_LNKCAP2_SLS_16_0GB 0x00000008 /* Supported Speed 16GT/s */ #define PCI_EXP_LNKCAP2_CROSSLINK 0x00000100 /* Crosslink supported */ #define PCI_EXP_LNKCTL2 48 /* Link Control 2 */ #define PCI_EXP_LNKCTL2_TLS 0x000f -- 2.16.1

6 years, 11 months

4
5
0 0

[PATCH] dm-bufio: adjust the reserved buffer for dm-verify-target.

by xiao jin

We hit the BUG() report at include/linux/scatterlist.h:144! The callback is as bellow: => verity_work => verity_hash_for_block => verity_verify_level => verity_hash => verity_hash_update => sg_init_one => sg_set_buf More debug shows the root cause. When creating dufio client it uses the __vmalloc() to allocate the buffer data for the reserved dm_buffer. The buffer that allocated by the __vmalloc() is invalid according to the __virt_addr_valid(). Mostly the reserved dm_buffer is not touched. But occasionally it might fail to allocate the dm_buffer data when we try to allocate in the __alloc_buffer_wait_no_callback(). Then it has to take the reserved dm_buffer for usage. Finally it reports the BUG() as virt_addr_valid() detects the buffer data address is invalid. The patch is to adjust the reserved buffer for dm-verity-target. We allocated two dm_buffers into the reserved buffers list when creating the buffer interface. The first dm_buffer in the reserved buffer list is allocated by the __vmalloc(), it's not used after that. The second dm_buffer in the reserved buffer list is allocated by the __get_free_pages() which can be consumed after that. Signed-off-by: xiao jin <jin.xiao(a)intel.com> --- drivers/md/dm-bufio.c | 4 ++-- drivers/md/dm-verity-target.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c index dc385b7..3b7ca5e 100644 --- a/drivers/md/dm-bufio.c +++ b/drivers/md/dm-bufio.c @@ -841,7 +841,7 @@ static struct dm_buffer *__alloc_buffer_wait_no_callback(struct dm_bufio_client tried_noio_alloc = true; } - if (!list_empty(&c->reserved_buffers)) { + if (!c->need_reserved_buffers) { b = list_entry(c->reserved_buffers.next, struct dm_buffer, lru_list); list_del(&b->lru_list); @@ -1701,7 +1701,7 @@ struct dm_bufio_client *dm_bufio_client_create(struct block_device *bdev, unsign goto bad; } - while (c->need_reserved_buffers) { + if (list_empty(&c->reserved_buffers)) { struct dm_buffer *b = alloc_buffer(c, GFP_KERNEL); if (!b) { diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c index 12decdbd7..40c66fc 100644 --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -1107,7 +1107,7 @@ static int verity_ctr(struct dm_target *ti, unsigned argc, char **argv) v->hash_blocks = hash_position; v->bufio = dm_bufio_client_create(v->hash_dev->bdev, - 1 << v->hash_dev_block_bits, 1, sizeof(struct buffer_aux), + 1 << v->hash_dev_block_bits, 2, sizeof(struct buffer_aux), dm_bufio_alloc_callback, NULL); if (IS_ERR(v->bufio)) { ti->error = "Cannot initialize dm-bufio"; -- 2.7.4

6 years, 11 months

3
2
0 0

+ zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2 has been added to the -mm tree. Its filename is zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/zram-remove-bd_cap_synchronous_io-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/zram-remove-bd_cap_synchronous_io-… 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: 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 zram-remove-bd_cap_synchronous_io-with-writeback-feature-v2.patch

6 years, 11 months

1
0
0 0

Backport Security Fix for CVE-2018-13095 to v4.14

by Yuki Machida

Hi Greg, I conformed that a patch of CVE-2018-13095 not applied at v4.14.60. Could you please apply a patch for 4.14-stable ? CVE-2018-13095 Upstream commit 23fcb3340d033d9f081e21e6c12c2db7eaa541d3 References https://nvd.nist.gov/vuln/detail/CVE-2018-13095 Regards, Yuki Machida

6 years, 11 months

3
3
0 0

[PATCH] drm/nouveau: Don't forget to cancel hpd_work on suspend/unload

by Lyude Paul

Currently, there's nothing in nouveau that actually cancels this work struct. So, cancel it on suspend/unload. Otherwise, if we're unlucky enough hpd_work might try to keep running up until the system is suspended. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/nouveau/nouveau_display.c | 9 ++++++--- drivers/gpu/drm/nouveau/nouveau_display.h | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index ec7861457b84..1ba3f152cfcb 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -425,7 +425,7 @@ nouveau_display_init(struct drm_device *dev) } void -nouveau_display_fini(struct drm_device *dev, bool suspend) +nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime) { struct nouveau_display *disp = nouveau_display(dev); struct nouveau_drm *drm = nouveau_drm(dev); @@ -450,6 +450,9 @@ nouveau_display_fini(struct drm_device *dev, bool suspend) } drm_connector_list_iter_end(&conn_iter); + if (!runtime) + cancel_work_sync(&drm->hpd_work); + drm_kms_helper_poll_disable(dev); disp->fini(dev); } @@ -618,11 +621,11 @@ nouveau_display_suspend(struct drm_device *dev, bool runtime) } } - nouveau_display_fini(dev, true); + nouveau_display_fini(dev, true, runtime); return 0; } - nouveau_display_fini(dev, true); + nouveau_display_fini(dev, true, runtime); list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { struct nouveau_framebuffer *nouveau_fb; diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h b/drivers/gpu/drm/nouveau/nouveau_display.h index 54aa7c3fa42d..ff92b54ce448 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.h +++ b/drivers/gpu/drm/nouveau/nouveau_display.h @@ -62,7 +62,7 @@ nouveau_display(struct drm_device *dev) int nouveau_display_create(struct drm_device *dev); void nouveau_display_destroy(struct drm_device *dev); int nouveau_display_init(struct drm_device *dev); -void nouveau_display_fini(struct drm_device *dev, bool suspend); +void nouveau_display_fini(struct drm_device *dev, bool suspend, bool runtime); int nouveau_display_suspend(struct drm_device *dev, bool runtime); void nouveau_display_resume(struct drm_device *dev, bool runtime); int nouveau_display_vblank_enable(struct drm_device *, unsigned int); diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index f5d3158f0378..20d4ab647cf7 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -629,7 +629,7 @@ nouveau_drm_unload(struct drm_device *dev) nouveau_debugfs_fini(drm); if (dev->mode_config.num_crtc) - nouveau_display_fini(dev, false); + nouveau_display_fini(dev, false, false); nouveau_display_destroy(dev); nouveau_bios_takedown(dev); -- 2.17.1

6 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror