January 2018 - Linux-stable-mirror

[Linux-stable-mirror] [PATCH v3 23/27] stating: ccree: fix allocation of void sized buf

by Gilad Ben-Yossef

We were allocating buffers using sizeof(*struct->field) where field was type void. Fix it by having a local variable with the real type. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> --- drivers/staging/ccree/ssi_ivgen.c | 9 ++++----- drivers/staging/ccree/ssi_sram_mgr.c | 9 ++++++--- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/staging/ccree/ssi_ivgen.c b/drivers/staging/ccree/ssi_ivgen.c index 6b92649..2ba15a5 100644 --- a/drivers/staging/ccree/ssi_ivgen.c +++ b/drivers/staging/ccree/ssi_ivgen.c @@ -175,13 +175,10 @@ int cc_ivgen_init(struct cc_drvdata *drvdata) int rc; /* Allocate "this" context */ - drvdata->ivgen_handle = kzalloc(sizeof(*drvdata->ivgen_handle), - GFP_KERNEL); - if (!drvdata->ivgen_handle) + ivgen_ctx = kzalloc(sizeof(*ivgen_ctx), GFP_KERNEL); + if (!ivgen_ctx) return -ENOMEM; - ivgen_ctx = drvdata->ivgen_handle; - /* Allocate pool's header for initial enc. key/IV */ ivgen_ctx->pool_meta = dma_alloc_coherent(device, CC_IVPOOL_META_SIZE, &ivgen_ctx->pool_meta_dma, @@ -200,6 +197,8 @@ int cc_ivgen_init(struct cc_drvdata *drvdata) goto out; } + drvdata->ivgen_handle = ivgen_ctx; + return cc_init_iv_sram(drvdata); out: diff --git a/drivers/staging/ccree/ssi_sram_mgr.c b/drivers/staging/ccree/ssi_sram_mgr.c index 1a2a7f4d..c5497aa 100644 --- a/drivers/staging/ccree/ssi_sram_mgr.c +++ b/drivers/staging/ccree/ssi_sram_mgr.c @@ -32,13 +32,16 @@ void cc_sram_mgr_fini(struct cc_drvdata *drvdata) */ int cc_sram_mgr_init(struct cc_drvdata *drvdata) { + struct cc_sram_ctx *ctx; + /* Allocate "this" context */ - drvdata->sram_mgr_handle = kzalloc(sizeof(*drvdata->sram_mgr_handle), - GFP_KERNEL); + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); - if (!drvdata->sram_mgr_handle) + if (!ctx) return -ENOMEM; + drvdata->sram_mgr_handle = ctx; + return 0; } -- 2.7.4

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH v3 14/27] staging: ccree: handle end of sg list gracefully

by Gilad Ben-Yossef

If we are asked for number of entries of an offset bigger than the sg list we should not crash. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> --- drivers/staging/ccree/ssi_buffer_mgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c b/drivers/staging/ccree/ssi_buffer_mgr.c index 78288ed..0f71264 100644 --- a/drivers/staging/ccree/ssi_buffer_mgr.c +++ b/drivers/staging/ccree/ssi_buffer_mgr.c @@ -94,7 +94,7 @@ static unsigned int cc_get_sgl_nents(struct device *dev, { unsigned int nents = 0; - while (nbytes) { + while (nbytes && sg_list) { if (sg_list->length) { nents++; /* get the number of bytes in the last entry */ -- 2.7.4

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH v3 13/27] staging: ccree: check DMA pool buf !NULL before free

by Gilad Ben-Yossef

If we ran out of DMA pool buffers, we get into the unmap code path with a NULL before. Deal with this by checking the virtual mapping is not NULL. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> --- drivers/staging/ccree/ssi_buffer_mgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c b/drivers/staging/ccree/ssi_buffer_mgr.c index e85bb53..78288ed 100644 --- a/drivers/staging/ccree/ssi_buffer_mgr.c +++ b/drivers/staging/ccree/ssi_buffer_mgr.c @@ -465,7 +465,8 @@ void cc_unmap_blkcipher_request(struct device *dev, void *ctx, DMA_TO_DEVICE); } /* Release pool */ - if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI) { + if (req_ctx->dma_buf_type == CC_DMA_BUF_MLLI && + req_ctx->mlli_params.mlli_virt_addr) { dma_pool_free(req_ctx->mlli_params.curr_pool, req_ctx->mlli_params.mlli_virt_addr, req_ctx->mlli_params.mlli_dma_addr); -- 2.7.4

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH v3 11/27] stating: ccree: revert "staging: ccree: fix leak of import() after init()"

by Gilad Ben-Yossef

This reverts commit c5f39d07860c ("staging: ccree: fix leak of import() after init()") and commit aece09024414 ("staging: ccree: Uninitialized return in ssi_ahash_import()"). This is the wrong solution and ends up relying on uninitialized memory, although it was not obvious to me at the time. Cc: stable(a)vger.kernel.org Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> --- drivers/staging/ccree/ssi_hash.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c index ff05ac8..ee7370c 100644 --- a/drivers/staging/ccree/ssi_hash.c +++ b/drivers/staging/ccree/ssi_hash.c @@ -1673,7 +1673,7 @@ static int cc_hash_import(struct ahash_request *req, const void *in) struct device *dev = drvdata_to_dev(ctx->drvdata); struct ahash_req_ctx *state = ahash_request_ctx(req); u32 tmp; - int rc = 0; + int rc; memcpy(&tmp, in, sizeof(u32)); if (tmp != CC_EXPORT_MAGIC) { @@ -1682,12 +1682,9 @@ static int cc_hash_import(struct ahash_request *req, const void *in) } in += sizeof(u32); - /* call init() to allocate bufs if the user hasn't */ - if (!state->digest_buff) { - rc = cc_hash_init(req); - if (rc) - goto out; - } + rc = cc_hash_init(req); + if (rc) + goto out; dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr, ctx->inter_digestsize, DMA_BIDIRECTIONAL); -- 2.7.4

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/AMD: Add support for fam17h microcode loading" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/AMD: Add support for fam17h microcode loading to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-microcode-amd-add-support-for-fam17h-microcode-loading.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf Mon Sep 17 00:00:00 2001 From: Tom Lendacky <thomas.lendacky(a)amd.com> Date: Thu, 30 Nov 2017 16:46:40 -0600 Subject: x86/microcode/AMD: Add support for fam17h microcode loading From: Tom Lendacky <thomas.lendacky(a)amd.com> commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf upstream. The size for the Microcode Patch Block (MPB) for an AMD family 17h processor is 3200 bytes. Add a #define for fam17h so that it does not default to 2048 bytes and fail a microcode load/update. Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Borislav Petkov <bp(a)alien8.de> Link: https://lkml.kernel.org/r/20171130224640.15391.40247.stgit@tlendack-t1.amdo… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Alice Ferrazzi <alicef(a)gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/amd.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -592,6 +592,7 @@ static unsigned int verify_patch_size(u8 #define F14H_MPB_MAX_SIZE 1824 #define F15H_MPB_MAX_SIZE 4096 #define F16H_MPB_MAX_SIZE 3458 +#define F17H_MPB_MAX_SIZE 3200 switch (family) { case 0x14: @@ -603,6 +604,9 @@ static unsigned int verify_patch_size(u8 case 0x16: max_size = F16H_MPB_MAX_SIZE; break; + case 0x17: + max_size = F17H_MPB_MAX_SIZE; + break; default: max_size = F1XH_MPB_MAX_SIZE; break; Patches currently in stable-queue which might be from thomas.lendacky(a)amd.com are queue-4.9/x86-microcode-amd-add-support-for-fam17h-microcode-loading.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/AMD: Add support for fam17h microcode loading" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/AMD: Add support for fam17h microcode loading to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-microcode-amd-add-support-for-fam17h-microcode-loading.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf Mon Sep 17 00:00:00 2001 From: Tom Lendacky <thomas.lendacky(a)amd.com> Date: Thu, 30 Nov 2017 16:46:40 -0600 Subject: x86/microcode/AMD: Add support for fam17h microcode loading From: Tom Lendacky <thomas.lendacky(a)amd.com> commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf upstream. The size for the Microcode Patch Block (MPB) for an AMD family 17h processor is 3200 bytes. Add a #define for fam17h so that it does not default to 2048 bytes and fail a microcode load/update. Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Borislav Petkov <bp(a)alien8.de> Link: https://lkml.kernel.org/r/20171130224640.15391.40247.stgit@tlendack-t1.amdo… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Alice Ferrazzi <alicef(a)gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/amd.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -580,6 +580,7 @@ static unsigned int verify_patch_size(u8 #define F14H_MPB_MAX_SIZE 1824 #define F15H_MPB_MAX_SIZE 4096 #define F16H_MPB_MAX_SIZE 3458 +#define F17H_MPB_MAX_SIZE 3200 switch (family) { case 0x14: @@ -591,6 +592,9 @@ static unsigned int verify_patch_size(u8 case 0x16: max_size = F16H_MPB_MAX_SIZE; break; + case 0x17: + max_size = F17H_MPB_MAX_SIZE; + break; default: max_size = F1XH_MPB_MAX_SIZE; break; Patches currently in stable-queue which might be from thomas.lendacky(a)amd.com are queue-4.4/x86-microcode-amd-add-support-for-fam17h-microcode-loading.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/microcode/AMD: Add support for fam17h microcode loading" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/microcode/AMD: Add support for fam17h microcode loading to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-microcode-amd-add-support-for-fam17h-microcode-loading.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf Mon Sep 17 00:00:00 2001 From: Tom Lendacky <thomas.lendacky(a)amd.com> Date: Thu, 30 Nov 2017 16:46:40 -0600 Subject: x86/microcode/AMD: Add support for fam17h microcode loading From: Tom Lendacky <thomas.lendacky(a)amd.com> commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf upstream. The size for the Microcode Patch Block (MPB) for an AMD family 17h processor is 3200 bytes. Add a #define for fam17h so that it does not default to 2048 bytes and fail a microcode load/update. Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Borislav Petkov <bp(a)alien8.de> Link: https://lkml.kernel.org/r/20171130224640.15391.40247.stgit@tlendack-t1.amdo… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: Alice Ferrazzi <alicef(a)gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/microcode/amd.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -470,6 +470,7 @@ static unsigned int verify_patch_size(u8 #define F14H_MPB_MAX_SIZE 1824 #define F15H_MPB_MAX_SIZE 4096 #define F16H_MPB_MAX_SIZE 3458 +#define F17H_MPB_MAX_SIZE 3200 switch (family) { case 0x14: @@ -481,6 +482,9 @@ static unsigned int verify_patch_size(u8 case 0x16: max_size = F16H_MPB_MAX_SIZE; break; + case 0x17: + max_size = F17H_MPB_MAX_SIZE; + break; default: max_size = F1XH_MPB_MAX_SIZE; break; Patches currently in stable-queue which might be from thomas.lendacky(a)amd.com are queue-4.14/x86-microcode-amd-add-support-for-fam17h-microcode-loading.patch queue-4.14/x86-pti-rename-bug_cpu_insecure-to-bug_cpu_meltdown.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "iommu/arm-smmu-v3: Don't free page table ops twice" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iommu/arm-smmu-v3: Don't free page table ops twice to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iommu-arm-smmu-v3-don-t-free-page-table-ops-twice.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 57d72e159b60456c8bb281736c02ddd3164037aa Mon Sep 17 00:00:00 2001 From: Jean-Philippe Brucker <jean-philippe.brucker(a)arm.com> Date: Thu, 14 Dec 2017 11:03:01 +0000 Subject: iommu/arm-smmu-v3: Don't free page table ops twice From: Jean-Philippe Brucker <jean-philippe.brucker(a)arm.com> commit 57d72e159b60456c8bb281736c02ddd3164037aa upstream. Kasan reports a double free when finalise_stage_fn fails: the io_pgtable ops are freed by arm_smmu_domain_finalise and then again by arm_smmu_domain_free. Prevent this by leaving pgtbl_ops empty on failure. Fixes: 48ec83bcbcf5 ("iommu/arm-smmu: Add initial driver support for ARM SMMUv3 devices") Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iommu/arm-smmu-v3.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -1547,13 +1547,15 @@ static int arm_smmu_domain_finalise(stru domain->pgsize_bitmap = pgtbl_cfg.pgsize_bitmap; domain->geometry.aperture_end = (1UL << ias) - 1; domain->geometry.force_aperture = true; - smmu_domain->pgtbl_ops = pgtbl_ops; ret = finalise_stage_fn(smmu_domain, &pgtbl_cfg); - if (ret < 0) + if (ret < 0) { free_io_pgtable_ops(pgtbl_ops); + return ret; + } - return ret; + smmu_domain->pgtbl_ops = pgtbl_ops; + return 0; } static __le64 *arm_smmu_get_step_for_sid(struct arm_smmu_device *smmu, u32 sid) Patches currently in stable-queue which might be from jean-philippe.brucker(a)arm.com are queue-4.9/iommu-arm-smmu-v3-don-t-free-page-table-ops-twice.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "Input: elantech - add new icbody type 15" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: elantech - add new icbody type 15 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: input-elantech-add-new-icbody-type-15.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 10d900303f1c3a821eb0bef4e7b7ece16768fba4 Mon Sep 17 00:00:00 2001 From: Aaron Ma <aaron.ma(a)canonical.com> Date: Sat, 25 Nov 2017 16:48:41 -0800 Subject: Input: elantech - add new icbody type 15 From: Aaron Ma <aaron.ma(a)canonical.com> commit 10d900303f1c3a821eb0bef4e7b7ece16768fba4 upstream. The touchpad of Lenovo Thinkpad L480 reports it's version as 15. Signed-off-by: Aaron Ma <aaron.ma(a)canonical.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/mouse/elantech.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/input/mouse/elantech.c +++ b/drivers/input/mouse/elantech.c @@ -1609,7 +1609,7 @@ static int elantech_set_properties(struc case 5: etd->hw_version = 3; break; - case 6 ... 14: + case 6 ... 15: etd->hw_version = 4; break; default: Patches currently in stable-queue which might be from aaron.ma(a)canonical.com are queue-4.9/input-elantech-add-new-icbody-type-15.patch

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "iommu/arm-smmu-v3: Cope with duplicated Stream IDs" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iommu/arm-smmu-v3: Cope with duplicated Stream IDs to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iommu-arm-smmu-v3-cope-with-duplicated-stream-ids.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 563b5cbe334e9503ab2b234e279d500fc4f76018 Mon Sep 17 00:00:00 2001 From: Robin Murphy <robin.murphy(a)arm.com> Date: Tue, 2 Jan 2018 12:33:14 +0000 Subject: iommu/arm-smmu-v3: Cope with duplicated Stream IDs From: Robin Murphy <robin.murphy(a)arm.com> commit 563b5cbe334e9503ab2b234e279d500fc4f76018 upstream. For PCI devices behind an aliasing PCIe-to-PCI/X bridge, the bridge alias to DevFn 0.0 on the subordinate bus may match the original RID of the device, resulting in the same SID being present in the device's fwspec twice. This causes trouble later in arm_smmu_write_strtab_ent() when we wind up visiting the STE a second time and find it already live. Avoid the issue by giving arm_smmu_install_ste_for_dev() the cleverness to skip over duplicates. It seems mildly counterintuitive compared to preventing the duplicates from existing in the first place, but since the DT and ACPI probe paths build their fwspecs differently, this is actually the cleanest and most self-contained way to deal with it. Fixes: 8f78515425da ("iommu/arm-smmu: Implement of_xlate() for SMMUv3") Reported-by: Tomasz Nowicki <tomasz.nowicki(a)caviumnetworks.com> Tested-by: Tomasz Nowicki <Tomasz.Nowicki(a)cavium.com> Tested-by: Jayachandran C. <jnair(a)caviumnetworks.com> Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/iommu/arm-smmu-v3.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -1582,7 +1582,7 @@ static __le64 *arm_smmu_get_step_for_sid static int arm_smmu_install_ste_for_dev(struct iommu_fwspec *fwspec) { - int i; + int i, j; struct arm_smmu_master_data *master = fwspec->iommu_priv; struct arm_smmu_device *smmu = master->smmu; @@ -1590,6 +1590,13 @@ static int arm_smmu_install_ste_for_dev( u32 sid = fwspec->ids[i]; __le64 *step = arm_smmu_get_step_for_sid(smmu, sid); + /* Bridged PCI devices may end up with duplicated IDs */ + for (j = 0; j < i; j++) + if (fwspec->ids[j] == sid) + break; + if (j < i) + continue; + arm_smmu_write_strtab_ent(smmu, sid, step, &master->ste); } Patches currently in stable-queue which might be from robin.murphy(a)arm.com are queue-4.9/iommu-arm-smmu-v3-cope-with-duplicated-stream-ids.patch queue-4.9/iommu-arm-smmu-v3-don-t-free-page-table-ops-twice.patch

6 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2018