September 2019 - Linux-stable-mirror

[PATCH] Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"

by Chris Wilson

The userptr put_pages can be called from inside try_to_unmap, and so enters with the page lock held on one of the object's backing pages. We cannot take the page lock ourselves for fear of recursion. Reported-by: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com> Reported-by: Martin Wilck <Martin.Wilck(a)suse.com> Reported-by: Leo Kraav <leho(a)kraav.com> Fixes: aa56a292ce62 ("drm/i915/userptr: Acquire the page lock around set_page_dirty()") References: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c index 74da35611d7c..11b231c187c5 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c @@ -672,15 +672,7 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj, for_each_sgt_page(page, sgt_iter, pages) { if (obj->mm.dirty) - /* - * As this may not be anonymous memory (e.g. shmem) - * but exist on a real mapping, we have to lock - * the page in order to dirty it -- holding - * the page reference is not sufficient to - * prevent the inode from being truncated. - * Play safe and take the lock. - */ - set_page_dirty_lock(page); + set_page_dirty(page); mark_page_accessed(page); put_page(page); -- 2.23.0

5 years, 3 months

2
1
0 0

[PATCH 01/23] drm/i915/dp: Fix dsc bpp calculations.

by Maarten Lankhorst

There was a integer wraparound when mode_clock became too high, and we didn't correct for the FEC overhead factor when dividing, also the calculations would break at HBR3. As a result our calculated bpp was way too high, and the link width bpp limitation never came into effect. Print out the resulting bpp calcululations as a sanity check, just in case we ever have to debug it later on again. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC") Cc: <stable(a)vger.kernel.org> # v5.0+ Cc: Manasi Navare <manasi.d.navare(a)intel.com> --- drivers/gpu/drm/i915/display/intel_dp.c | 20 +++++++++++--------- drivers/gpu/drm/i915/display/intel_dp.h | 4 ++-- 2 files changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index d09133a958e1..a7e392f8adeb 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4363,10 +4363,10 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 *sink_irq_vector) DP_DPRX_ESI_LEN; } -u16 intel_dp_dsc_get_output_bpp(int link_clock, u8 lane_count, - int mode_clock, int mode_hdisplay) +u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u32 lane_count, + u32 mode_clock, u32 mode_hdisplay) { - u16 bits_per_pixel, max_bpp_small_joiner_ram; + u32 bits_per_pixel, max_bpp_small_joiner_ram; int i; /* @@ -4375,13 +4375,14 @@ u16 intel_dp_dsc_get_output_bpp(int link_clock, u8 lane_count, * FECOverhead = 2.4%, for SST -> TimeSlotsPerMTP is 1, * for MST -> TimeSlotsPerMTP has to be calculated */ - bits_per_pixel = (link_clock * lane_count * 8 * - DP_DSC_FEC_OVERHEAD_FACTOR) / - mode_clock; + bits_per_pixel = + mul_u32_u32(link_clock, lane_count * 8 * DP_DSC_FEC_OVERHEAD_FACTOR) / + mul_u32_u32(1000ULL, mode_clock); + DRM_DEBUG_KMS("Max link bpp: %u\n", bits_per_pixel); /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */ - max_bpp_small_joiner_ram = DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER / - mode_hdisplay; + max_bpp_small_joiner_ram = DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER / mode_hdisplay; + DRM_DEBUG_KMS("Max small joiner bpp: %u\n", max_bpp_small_joiner_ram); /* * Greatest allowed DSC BPP = MIN (output BPP from avaialble Link BW @@ -4391,7 +4392,8 @@ u16 intel_dp_dsc_get_output_bpp(int link_clock, u8 lane_count, /* Error out if the max bpp is less than smallest allowed valid bpp */ if (bits_per_pixel < valid_dsc_bpp[0]) { - DRM_DEBUG_KMS("Unsupported BPP %d\n", bits_per_pixel); + DRM_DEBUG_KMS("Unsupported BPP %u, min %u\n", + bits_per_pixel, valid_dsc_bpp[0]); return 0; } diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h index e01d1f89409d..586dc9336d63 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.h +++ b/drivers/gpu/drm/i915/display/intel_dp.h @@ -103,8 +103,8 @@ bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp); bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp); bool intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status); -u16 intel_dp_dsc_get_output_bpp(int link_clock, u8 lane_count, - int mode_clock, int mode_hdisplay); +u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u32 lane_count, + u32 mode_clock, u32 mode_hdisplay); u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp, int mode_clock, int mode_hdisplay); -- 2.20.1

5 years, 3 months

1
0
0 0

[PATCH v2] KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl

by Thomas Huth

When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject an interrupt, we convert them from the legacy struct kvm_s390_interrupt to the new struct kvm_s390_irq via the s390int_to_s390irq() function. However, this function does not take care of all types of interrupts that we can inject into the guest later (see do_inject_vcpu()). Since we do not clear out the s390irq values before calling s390int_to_s390irq(), there is a chance that we copy random data from the kernel stack which could be leaked to the userspace later. Specifically, the problem exists with the KVM_S390_INT_PFAULT_INIT interrupt: s390int_to_s390irq() does not handle it, and the function __inject_pfault_init() later copies irq->u.ext which contains the random kernel stack data. This data can then be leaked either to the guest memory in __deliver_pfault_init(), or the userspace might retrieve it directly with the KVM_S390_GET_IRQ_STATE ioctl. Fix it by handling that interrupt type in s390int_to_s390irq(), too, and by making sure that the s390irq struct is properly pre-initialized. And while we're at it, make sure that s390int_to_s390irq() now directly returns -EINVAL for unknown interrupt types, so that we immediately get a proper error code in case we add more interrupt types to do_inject_vcpu() without updating s390int_to_s390irq() sometime in the future. Cc: stable(a)vger.kernel.org Reviewed-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Signed-off-by: Thomas Huth <thuth(a)redhat.com> --- arch/s390/kvm/interrupt.c | 10 ++++++++++ arch/s390/kvm/kvm-s390.c | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c index 3e7efdd9228a..165dea4c7f19 100644 --- a/arch/s390/kvm/interrupt.c +++ b/arch/s390/kvm/interrupt.c @@ -1960,6 +1960,16 @@ int s390int_to_s390irq(struct kvm_s390_interrupt *s390int, case KVM_S390_MCHK: irq->u.mchk.mcic = s390int->parm64; break; + case KVM_S390_INT_PFAULT_INIT: + irq->u.ext.ext_params = s390int->parm; + irq->u.ext.ext_params2 = s390int->parm64; + break; + case KVM_S390_RESTART: + case KVM_S390_INT_CLOCK_COMP: + case KVM_S390_INT_CPU_TIMER: + break; + default: + return -EINVAL; } return 0; } diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index f329dcb3f44c..082eac2abc88 100644 --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -4323,7 +4323,7 @@ long kvm_arch_vcpu_async_ioctl(struct file *filp, } case KVM_S390_INTERRUPT: { struct kvm_s390_interrupt s390int; - struct kvm_s390_irq s390irq; + struct kvm_s390_irq s390irq = {}; if (copy_from_user(&s390int, argp, sizeof(s390int))) return -EFAULT; -- 2.18.1

5 years, 3 months

3
2
0 0

[PATCH 4.4] x86, boot: Remove multiple copy of static function sanitize_boot_params()

by Nathan Chancellor

From: Zhenzhong Duan <zhenzhong.duan(a)oracle.com> commit 8c5477e8046ca139bac250386c08453da37ec1ae upstream. Kernel build warns: 'sanitize_boot_params' defined but not used [-Wunused-function] at below files: arch/x86/boot/compressed/cmdline.c arch/x86/boot/compressed/error.c arch/x86/boot/compressed/early_serial_console.c arch/x86/boot/compressed/acpi.c That's becausethey each include misc.h which includes a definition of sanitize_boot_params() via bootparam_utils.h. Remove the inclusion from misc.h and have the c file including bootparam_utils.h directly. Signed-off-by: Zhenzhong Duan <zhenzhong.duan(a)oracle.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Link: https://lkml.kernel.org/r/1563283092-1189-1-git-send-email-zhenzhong.duan@o… [nc: Fixed conflict around lack of 67b6662559f7f] Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> --- Hi Greg and Sasha, Please consider applying this to 4.4 as it resolves a compilation error with clang on 4.4 and it has already been applied to 4.9 and newer: https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/232287034 https://github.com/ClangBuiltLinux/linux/issues/654 Thanks to Ilie Halip for debugging this; TL;DR: clang pretends that it is GCC 4.2.1 for glibc compatibility and this trips up a definition of memcpy for GCC < 4.3. This is not an issue on mainline because GCC 4.6 is the earliest supported GCC version so that code was removed and this patch resolves it because string.h redefines memcpy to a proper version. arch/x86/boot/compressed/misc.c | 1 + arch/x86/boot/compressed/misc.h | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c index 16df89c30c20..1e5b68228aff 100644 --- a/arch/x86/boot/compressed/misc.c +++ b/arch/x86/boot/compressed/misc.c @@ -11,6 +11,7 @@ #include "misc.h" #include "../string.h" +#include <asm/bootparam_utils.h> /* WARNING!! * This code is compiled with -fPIC and it is relocated dynamically diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h index 4abb284a5b9c..bce182708814 100644 --- a/arch/x86/boot/compressed/misc.h +++ b/arch/x86/boot/compressed/misc.h @@ -19,7 +19,6 @@ #include <asm/page.h> #include <asm/boot.h> #include <asm/bootparam.h> -#include <asm/bootparam_utils.h> #define BOOT_BOOT_H #include "../ctype.h" -- 2.23.0

5 years, 3 months

2
1
0 0

Re: [PATCH 5.2 19/94] net/rds: Fix info leak in rds6_inc_info_copy()

by Greg Kroah-Hartman

On Thu, Sep 12, 2019 at 04:38:25PM +0800, butt3rflyh4ck wrote: > can the issue assigned a CVE number？please reply on me as soon as possible. > thank you As per the kernel documentation, the kernel community does not assign, or deal with, CVEs numbers at all. Just go ask for one directly from MITRE if you really feel you need one (hint, there is no real need...) thanks, greg k-h

5 years, 3 months

1
0
0 0

[PATCH V2] dm-raid: fix updating of max_discard_sectors limit

by Ming Lei

Unit of 'chunk_size' is byte, instead of sector, so fix it. Without this fix, too big max_discard_sectors is applied on the request queue of dm-raid, finally raid code has to split the bio again. This re-split done by raid causes the following nested clone_endio: 1) one big bio 'A' is submitted to dm queue, and served as the original bio 2) one new bio 'B' is cloned from the original bio 'A', and .map() is run on this bio of 'B', and B's original bio points to 'A' 3) raid code sees that 'B' is too big, and split 'B' and re-submit the remainded part of 'B' to dm-raid queue via generic_make_request(). 4) now dm will hanlde 'B' as new original bio, then allocate a new clone bio of 'C' and run .map() on 'C'. Meantime C's original bio points to 'B'. 5) suppose now 'C' is completed by raid direclty, then the following clone_endio() is called recursively: clone_endio(C) ->clone_endio(B) #B is original bio of 'C' ->bio_endio(A) 'A' can be big enough to make handreds of nested clone_endio(), then stack can be corrupted easily. Cc: <stable(a)vger.kernel.org> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- V2: - fix commit log a bit drivers/md/dm-raid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c index 8a60a4a070ac..c26aa4e8207a 100644 --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -3749,7 +3749,7 @@ static void raid_io_hints(struct dm_target *ti, struct queue_limits *limits) */ if (rs_is_raid1(rs) || rs_is_raid10(rs)) { limits->discard_granularity = chunk_size; - limits->max_discard_sectors = chunk_size; + limits->max_discard_sectors = chunk_size >> 9; } } -- 2.20.1

5 years, 4 months

4
4
0 0

Re: [PATCH v2] SUNRPC: Dequeue the request from the receive queue while we're re-encoding

by Sasha Levin

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 753690898204 SUNRPC: Ensure the bvecs are reset when we re-encode the RPC request. The bot has tested the following trees: v5.2.14. v5.2.14: Failed to apply! Possible dependencies: b5e924191f87 ("SUNRPC: Remove the bh-safe lock requirement on xprt->transport_lock") NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? -- Thanks, Sasha

5 years, 4 months

1
0
0 0

[PATCH] dm-raid: fix updating of max_discard_sectors limit

by Ming Lei

Unit of 'chunk_size' is byte, instead of sector, so fix it. Without this fix, too big max_discard_sectors is applied on the request queue of dm-raid, finally raid code has to split the bio again. This re-split by raid may cause the following nested clone_endio: 1) one big bio 'A' is submitted to dm queue, and served as the original bio 2) one new bio 'B' is cloned from the original bio 'A', and .map() is run on this bio of 'B', and B's original bio points to 'A' 3) raid code sees that 'B' is too big, and split 'B' and re-submit the remainded part of 'B' to dm-raid queue via generic_make_request(). 4) now dm will hanlde 'B' as new original bio, then allocate a new clone bio of 'C' and run .map() on 'C'. Meantime C's original bio points to 'B'. 5) suppose now 'C' can be completed by raid direclty, then the following clone_endio() is called recursively: clone_endio(C) ->clone_endio(B) #B is original bio of 'C' ->clone_endio(A) #A is original bio of 'B' 'A' can be big enough to make such handreds of nested clone_endio(), then stack is corrupted. Cc: <stable(a)vger.kernel.org> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- drivers/md/dm-raid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c index 8a60a4a070ac..c26aa4e8207a 100644 --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -3749,7 +3749,7 @@ static void raid_io_hints(struct dm_target *ti, struct queue_limits *limits) */ if (rs_is_raid1(rs) || rs_is_raid10(rs)) { limits->discard_granularity = chunk_size; - limits->max_discard_sectors = chunk_size; + limits->max_discard_sectors = chunk_size >> 9; } } -- 2.20.1

5 years, 4 months

2
1
0 0

[PATCH 4/4] scsi: qla2xxx: Change discovery state before PLOGI

by Roman Bolshakov

When a port sends PLOGI, discovery state should be changed to login pending, otherwise RELOGIN_NEEDED bit is set in qla24xx_handle_plogi_done_event(). RELOGIN_NEEDED triggers another PLOGI, and it never goes out of the loop until login timer expires. Fixes: 8777e4314d397 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine") Fixes: 8b5292bcfcacf ("scsi: qla2xxx: Fix Relogin to prevent modifying scan_state flag") Cc: Quinn Tran <qtran(a)marvell.com> Cc: Himanshu Madhani <hmadhani(a)marvell.com> Cc: stable(a)vger.kernel.org Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com> --- drivers/scsi/qla2xxx/qla_init.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c index c8d89912d044..e4857ef0e5c4 100644 --- a/drivers/scsi/qla2xxx/qla_init.c +++ b/drivers/scsi/qla2xxx/qla_init.c @@ -516,6 +516,7 @@ static int qla_post_els_plogi_work(struct scsi_qla_host *vha, fc_port_t *fcport) e->u.fcport.fcport = fcport; fcport->flags |= FCF_ASYNC_ACTIVE; + fcport->disc_state = DSC_LOGIN_PEND; return qla2x00_post_work(vha, e); } -- 2.22.0

5 years, 4 months

1
0
0 0

[PATCH 2/4] scsi: qla2xxx: Initialize free_work before flushing it

by Roman Bolshakov

Target creation triggers a new BUG_ON introduced in in 4d43d395fed12 ("workqueue: Try to catch flush_work() without INIT_WORK()."). The BUG_ON reveals an attempt to flush free_work in qla24xx_do_nack_work before it's initialized in qlt_unreg_sess: WARNING: CPU: 7 PID: 211 at kernel/workqueue.c:3031 __flush_work.isra.38+0x40/0x2e0 CPU: 7 PID: 211 Comm: kworker/7:1 Kdump: loaded Tainted: G E 5.3.0-rc7-vanilla+ #2 Workqueue: qla2xxx_wq qla2x00_iocb_work_fn [qla2xxx] NIP: c000000000159620 LR: c0080000009d91b0 CTR: c0000000001598c0 REGS: c000000005f3f730 TRAP: 0700 Tainted: G E (5.3.0-rc7-vanilla+) MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002222 XER: 00000000 CFAR: c0000000001598d0 IRQMASK: 0 GPR00: c0080000009d91b0 c000000005f3f9c0 c000000001670a00 c0000003f8655ca8 GPR04: c0000003f8655c00 000000000000ffff 0000000000000011 ffffffffffffffff GPR08: c008000000949228 0000000000000000 0000000000000001 c0080000009e7780 GPR12: 0000000000002200 c00000003fff6200 c000000000161bc8 0000000000000004 GPR16: c0000003f9d68280 0000000002000000 0000000000000005 0000000000000003 GPR20: 0000000000000002 000000000000ffff 0000000000000000 fffffffffffffef7 GPR24: c000000004f73848 c000000004f73838 c000000004f73f28 c000000005f3fb60 GPR28: c000000004f73e48 c000000004f73c80 c000000004f73818 c0000003f9d68280 NIP [c000000000159620] __flush_work.isra.38+0x40/0x2e0 LR [c0080000009d91b0] qla24xx_do_nack_work+0x88/0x180 [qla2xxx] Call Trace: [c000000005f3f9c0] [c000000000159644] __flush_work.isra.38+0x64/0x2e0 (unreliable) [c000000005f3fa50] [c0080000009d91a0] qla24xx_do_nack_work+0x78/0x180 [qla2xxx] [c000000005f3fae0] [c0080000009496ec] qla2x00_do_work+0x604/0xb90 [qla2xxx] [c000000005f3fc40] [c008000000949cd8] qla2x00_iocb_work_fn+0x60/0xe0 [qla2xxx] [c000000005f3fc80] [c000000000157bb8] process_one_work+0x2c8/0x5b0 [c000000005f3fd10] [c000000000157f28] worker_thread+0x88/0x660 [c000000005f3fdb0] [c000000000161d64] kthread+0x1a4/0x1b0 [c000000005f3fe20] [c00000000000b960] ret_from_kernel_thread+0x5c/0x7c Instruction dump: 3d22001d 892966b1 7d908026 91810008 f821ff71 69290001 0b090000 2e290000 40920200 e9230018 7d2a0074 794ad182 <0b0a0000> 2fa90000 419e01e8 7c0802a6 ---[ end trace 5ccf335d4f90fcb8 ]--- Fixes: 1021f0bc2f3d6 ("scsi: qla2xxx: allow session delete to finish before create.") Cc: Quinn Tran <qtran(a)marvell.com> Cc: Himanshu Madhani <hmadhani(a)marvell.com> Cc: stable(a)vger.kernel.org Signed-off-by: Roman Bolshakov <r.bolshakov(a)yadro.com> --- drivers/scsi/qla2xxx/qla_init.c | 1 + drivers/scsi/qla2xxx/qla_target.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c index cb08004ef3f8..c8d89912d044 100644 --- a/drivers/scsi/qla2xxx/qla_init.c +++ b/drivers/scsi/qla2xxx/qla_init.c @@ -4803,6 +4803,7 @@ qla2x00_alloc_fcport(scsi_qla_host_t *vha, gfp_t flags) } INIT_WORK(&fcport->del_work, qla24xx_delete_sess_fn); + INIT_WORK(&fcport->free_work, qlt_free_session_done); INIT_WORK(&fcport->reg_work, qla_register_fcport_fn); INIT_LIST_HEAD(&fcport->gnl_entry); INIT_LIST_HEAD(&fcport->list); diff --git a/drivers/scsi/qla2xxx/qla_target.c b/drivers/scsi/qla2xxx/qla_target.c index 0ffda6171614..bd1d30524de5 100644 --- a/drivers/scsi/qla2xxx/qla_target.c +++ b/drivers/scsi/qla2xxx/qla_target.c @@ -1160,7 +1160,6 @@ void qlt_unreg_sess(struct fc_port *sess) sess->last_rscn_gen = sess->rscn_gen; sess->last_login_gen = sess->login_gen; - INIT_WORK(&sess->free_work, qlt_free_session_done); schedule_work(&sess->free_work); } EXPORT_SYMBOL(qlt_unreg_sess); -- 2.22.0

5 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2019