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

Re: [PATCH 5.6 000/126] 5.6.15-rc1 review

by Ronald Warsow

hallo 5.6.15-rc1 compiles, boots and works without errors here on an Intel-i7-6700-box Thanks ! -- regards Ronald

5 years, 7 months

1
0
0 0

Re: Patch "ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"" has been added to the 4.4-stable tree

by Eric Biggers

On Sun, May 24, 2020 at 09:52:54AM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > ppp: mppe: Revert "ppp: mppe: Add softdep to arc4" > > 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: > ppp-mppe-revert-ppp-mppe-add-softdep-to-arc4.patch > and it can be found in the queue-4.4 subdirectory. I already explained last time that this shouldn't be backported: https://lore.kernel.org/stable/20190905161642.GA5659@google.com/ The commit message explains it too. Is there something I could have done last time around to properly prevent this from being backported, or do I have to continue to be ready to respond to these emails which can come at arbitrary times forever? > > 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. Hard for "anyone else" to object to it when you didn't Cc any real mailing lists (stable-commits doesn't count) and just sent this to me. Lucky I saw this. - Eric

5 years, 7 months

2
2
0 0

Re: [PATCH v1] driver core: Update device link status correctly for SYNC_STATE_ONLY links

by Saravana Kannan

On Tue, May 26, 2020 at 12:05 AM Saravana Kannan <saravanak(a)google.com> wrote: > > When SYNC_STATE_ONLY support was added in commit 05ef983e0d65 ("driver > core: Add device link support for SYNC_STATE_ONLY flag"), > SYNC_STATE_ONLY links were treated similar to STATELESS links in terms > of not blocking consumer probe if the supplier hasn't probed yet. > > That caused a SYNC_STATE_ONLY device link's status to not get updated. > Since SYNC_STATE_ONLY device link is no longer useful once the > consumer probes, commit 21c27f06587d ("driver core: Fix > SYNC_STATE_ONLY device link implementation") addresses the status > update issue by deleting the SYNC_STATE_ONLY device link instead of > complicating the status update code. > > However, there are still some cases where we need to update the status > of a SYNC_STATE_ONLY device link. A SYNC_STATE_ONLY device link can > later get converted into a normal MANAGED device link when a normal > MANAGED device link is created between a supplier and consumer that > already have a SYNC_STATE_ONLY device link between them. If a > SYNC_STATE_ONLY device link's status isn't maintained correctly till > it's converted to a normal MANAGED device link, then the normal > MANAGED device link will end up with a wrong link status. This can > cause a warning stack trace[1] when the consumer device probes. > > This commit fixes the SYNC_STATE_ONLY device link status update issue > where it wouldn't transition correctly from DL_STATE_AVAILABLE to > DL_STATE_CONSUMER_PROBE. > > [1] - https://lore.kernel.org/lkml/20200522204120.3b3c9ed6@apollo/ > Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag") > Fixes: 21c27f06587d ("driver core: Fix SYNC_STATE_ONLY device link implementation") > Reported-by: Michael Walle <michael(a)walle.cc> > Signed-off-by: Saravana Kannan <saravanak(a)google.com> > --- > Greg, > > I think this is the issue Michael ran into. I'd like him to test the fix > before it's pulled in. > > Michael, > > If you can test this on the branch you saw the issue in and give a > Tested-by if it works, that'd be great. > > Thanks, > Saravana > > drivers/base/core.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/base/core.c b/drivers/base/core.c > index 791b7530599f..9511be3f9a32 100644 > --- a/drivers/base/core.c > +++ b/drivers/base/core.c > @@ -687,11 +687,11 @@ int device_links_check_suppliers(struct device *dev) > device_links_write_lock(); > > list_for_each_entry(link, &dev->links.suppliers, c_node) { > - if (!(link->flags & DL_FLAG_MANAGED) || > - link->flags & DL_FLAG_SYNC_STATE_ONLY) > + if (!(link->flags & DL_FLAG_MANAGED)) > continue; > > - if (link->status != DL_STATE_AVAILABLE) { > + if (link->status != DL_STATE_AVAILABLE && > + !(link->flags & DL_FLAG_SYNC_STATE_ONLY)) { > device_links_missing_supplier(dev); > ret = -EPROBE_DEFER; > break; > -- > 2.27.0.rc0.183.gde8f92d652-goog > Adding stable@ that I forgot to add earlier. -Saravana

5 years, 7 months

2
2
0 0

[tip: ras/core] x86/{mce,mm}: Change so poison pages are either unmapped or marked uncacheable

by tip-bot2 for Tony Luck

The following commit has been merged into the ras/core branch of tip: Commit-ID: 3cb1ada80fe29e2fa022b5f20370b65718e0a744 Gitweb: https://git.kernel.org/tip/3cb1ada80fe29e2fa022b5f20370b65718e0a744 Author: Tony Luck <tony.luck(a)intel.com> AuthorDate: Wed, 20 May 2020 09:35:46 -07:00 Committer: Borislav Petkov <bp(a)suse.de> CommitterDate: Mon, 25 May 2020 12:46:40 +02:00 x86/{mce,mm}: Change so poison pages are either unmapped or marked uncacheable An interesting thing happened when a guest Linux instance took a machine check. The VMM unmapped the bad page from guest physical space and passed the machine check to the guest. Linux took all the normal actions to offline the page from the process that was using it. But then guest Linux crashed because it said there was a second machine check inside the kernel with this stack trace: do_memory_failure set_mce_nospec set_memory_uc _set_memory_uc change_page_attr_set_clr cpa_flush clflush_cache_range_opt This was odd, because a CLFLUSH instruction shouldn't raise a machine check (it isn't consuming the data). Further investigation showed that the VMM had passed in another machine check because is appeared that the guest was accessing the bad page. Fix is to check the scope of the poison by checking the MCi_MISC register. If the entire page is affected, then unmap the page. If only part of the page is affected, then mark the page as uncacheable. This assumes that VMMs will do the logical thing and pass in the "whole page scope" via the MCi_MISC register (since they unmapped the entire page). Fixes: 284ce4011ba6 ("x86/memory_failure: Introduce {set, clear}_mce_nospec()") Reported-by: Jue Wang <juew(a)google.com> Signed-off-by: Tony Luck <tony.luck(a)intel.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Tested-by: Jue Wang <juew(a)google.com> Cc: <stable(a)vger.kernel.org> Link: https://lkml.kernel.org/r/20200520163546.GA7977@agluck-desk2.amr.corp.intel… --- arch/x86/include/asm/set_memory.h | 19 +++++++++++++------ arch/x86/kernel/cpu/mce/core.c | 11 +++++++++-- include/linux/set_memory.h | 2 +- 3 files changed, 23 insertions(+), 9 deletions(-) diff --git a/arch/x86/include/asm/set_memory.h b/arch/x86/include/asm/set_memory.h index ec2c0a0..5948218 100644 --- a/arch/x86/include/asm/set_memory.h +++ b/arch/x86/include/asm/set_memory.h @@ -86,28 +86,35 @@ int set_direct_map_default_noflush(struct page *page); extern int kernel_set_to_readonly; #ifdef CONFIG_X86_64 -static inline int set_mce_nospec(unsigned long pfn) +/* + * Prevent speculative access to the page by either unmapping + * it (if we do not require access to any part of the page) or + * marking it uncacheable (if we want to try to retrieve data + * from non-poisoned lines in the page). + */ +static inline int set_mce_nospec(unsigned long pfn, bool unmap) { unsigned long decoy_addr; int rc; /* - * Mark the linear address as UC to make sure we don't log more - * errors because of speculative access to the page. * We would like to just call: - * set_memory_uc((unsigned long)pfn_to_kaddr(pfn), 1); + * set_memory_XX((unsigned long)pfn_to_kaddr(pfn), 1); * but doing that would radically increase the odds of a * speculative access to the poison page because we'd have * the virtual address of the kernel 1:1 mapping sitting * around in registers. * Instead we get tricky. We create a non-canonical address * that looks just like the one we want, but has bit 63 flipped. - * This relies on set_memory_uc() properly sanitizing any __pa() + * This relies on set_memory_XX() properly sanitizing any __pa() * results with __PHYSICAL_MASK or PTE_PFN_MASK. */ decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63)); - rc = set_memory_uc(decoy_addr, 1); + if (unmap) + rc = set_memory_np(decoy_addr, 1); + else + rc = set_memory_uc(decoy_addr, 1); if (rc) pr_warn("Could not invalidate pfn=0x%lx from 1:1 map\n", pfn); return rc; diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c index 02e1f16..e35aece 100644 --- a/arch/x86/kernel/cpu/mce/core.c +++ b/arch/x86/kernel/cpu/mce/core.c @@ -518,6 +518,13 @@ bool mce_is_memory_error(struct mce *m) } EXPORT_SYMBOL_GPL(mce_is_memory_error); +static bool whole_page(struct mce *m) +{ + if (!mca_cfg.ser || !(m->status & MCI_STATUS_MISCV)) + return true; + return MCI_MISC_ADDR_LSB(m->misc) >= PAGE_SHIFT; +} + bool mce_is_correctable(struct mce *m) { if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED) @@ -571,7 +578,7 @@ static int uc_decode_notifier(struct notifier_block *nb, unsigned long val, pfn = mce->addr >> PAGE_SHIFT; if (!memory_failure(pfn, 0)) { - set_mce_nospec(pfn); + set_mce_nospec(pfn, whole_page(mce)); mce->kflags |= MCE_HANDLED_UC; } @@ -1069,7 +1076,7 @@ static int do_memory_failure(struct mce *m) if (ret) pr_err("Memory error not recovered"); else - set_mce_nospec(m->addr >> PAGE_SHIFT); + set_mce_nospec(m->addr >> PAGE_SHIFT, whole_page(m)); return ret; } diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h index 86281ac..860e0f8 100644 --- a/include/linux/set_memory.h +++ b/include/linux/set_memory.h @@ -26,7 +26,7 @@ static inline int set_direct_map_default_noflush(struct page *page) #endif #ifndef set_mce_nospec -static inline int set_mce_nospec(unsigned long pfn) +static inline int set_mce_nospec(unsigned long pfn, bool unmap) { return 0; }

5 years, 7 months

3
2
0 0

[PATCH 00/27] more l2tp locking and ordering fixes

by Giuliano Procida

Hi Greg. This is for 4.4. This is a follow-up to "l2tp locking and ordering fixes" for 4.9. Compared with that series, this pulls in 5 more patches (the first 5 Guillaume Nault ones below) containing more of the same as well as making later changes apply more cleanly. As before, every commit compiles with make allmodconfig, but I have no hardware to test this with. 9dd79945b0f8 (use IS_ENABLED) would have made one patch or so cleaner but I didn't add it. There are also bunch of fixes that aren't l2tp locking or ordering fixes and I didn't add them either. For the record... Between 4.4 and 4.9: 018f82585823 net: l2tp: fix reversed udp6 checksum flags 56cff471d0c6 l2tp: Fix the connect status check in pppol2tp_getname 286c72deabaa udp: must lock the socket in udp_disconnect() df90e6886146 l2tp: fix lookup for sockets not bound to a device in l2tp_ip 31e2f21fb35b l2tp: fix address test in __l2tp_ip6_bind_lookup() Between 4.9 and 4.9.latest: 000224c1106c l2tp: consider '::' as wildcard address in l2tp_ip6 socket lookup d2d74d0e58b2 l2tp: take remote address into account in l2tp_ip and l2tp_ip6 socket lookups 65b05d03a578 l2tp: remove configurable payload offset b437ed583592 l2tp: Fix possible NULL pointer dereference Regards, Giuliano. Asbjørn Sloth Tønnesen (3): net: l2tp: export debug flags to UAPI net: l2tp: deprecate PPPOL2TP_MSG_* in favour of L2TP_MSG_* net: l2tp: ppp: change PPPOL2TP_MSG_* => L2TP_MSG_* Guillaume Nault (22): l2tp: lock socket before checking flags in connect() l2tp: fix racy socket lookup in l2tp_ip and l2tp_ip6 bind() l2tp: hold session while sending creation notifications l2tp: take a reference on sessions used in genetlink handlers l2tp: don't use l2tp_tunnel_find() in l2tp_ip and l2tp_ip6 l2tp: remove useless duplicate session detection in l2tp_netlink l2tp: remove l2tp_session_find() l2tp: define parameters of l2tp_session_get*() as "const" l2tp: define parameters of l2tp_tunnel_find*() as "const" l2tp: initialise session's refcount before making it reachable l2tp: hold tunnel while looking up sessions in l2tp_netlink l2tp: hold tunnel while processing genl delete command l2tp: hold tunnel while handling genl tunnel updates l2tp: hold tunnel while handling genl TUNNEL_GET commands l2tp: hold tunnel used while creating sessions with netlink l2tp: prevent creation of sessions on terminated tunnels l2tp: pass tunnel pointer to ->session_create() l2tp: fix l2tp_eth module loading l2tp: don't register sessions in l2tp_session_create() l2tp: initialise l2tp_eth sessions before registering them l2tp: protect sock pointer of struct pppol2tp_session with RCU l2tp: initialise PPP sessions before registering them R. Parameswaran (2): New kernel function to get IP overhead on a socket. L2TP:Adjust intf MTU, add underlay L3, L2 hdrs. Documentation/networking/l2tp.txt | 8 +- include/linux/net.h | 3 + include/net/ipv6.h | 2 + include/uapi/linux/if_pppol2tp.h | 13 +- include/uapi/linux/l2tp.h | 17 +- net/ipv6/datagram.c | 4 +- net/l2tp/l2tp_core.c | 181 ++++++----------- net/l2tp/l2tp_core.h | 47 +++-- net/l2tp/l2tp_eth.c | 214 +++++++++++++-------- net/l2tp/l2tp_ip.c | 68 ++++--- net/l2tp/l2tp_ip6.c | 82 ++++---- net/l2tp/l2tp_netlink.c | 124 +++++++----- net/l2tp/l2tp_ppp.c | 309 ++++++++++++++++++------------ net/socket.c | 46 +++++ 14 files changed, 629 insertions(+), 489 deletions(-) -- 2.27.0.rc0.183.gde8f92d652-goog

5 years, 7 months

3
29
0 0

Canada Offer

by Felix

I hope you are doing great? This is Felix from Toronto-Canada. I have a lucrative business offer that will benefit us both immensely within a very short period of time. However, I need your initial approval of interest prior to further and complete details regarding the deal. Thanks, Felix.

5 years, 7 months

1
0
0 0

[PATCH v1] clk: mediatek: assign the initial value to clk_init_data of mtk_mux

by Weiyi Lu

It'd be dangerous when struct clk_core have new memebers. Add the missing initial value to clk_init_data. Fixes: a3ae549917f1 ("clk: mediatek: Add new clkmux register API") Cc: <stable(a)vger.kernel.org> Signed-off-by: Weiyi Lu <weiyi.lu(a)mediatek.com> --- drivers/clk/mediatek/clk-mux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/mediatek/clk-mux.c b/drivers/clk/mediatek/clk-mux.c index 76f9cd0..14e127e 100644 --- a/drivers/clk/mediatek/clk-mux.c +++ b/drivers/clk/mediatek/clk-mux.c @@ -160,7 +160,7 @@ struct clk *mtk_clk_register_mux(const struct mtk_mux *mux, spinlock_t *lock) { struct mtk_clk_mux *clk_mux; - struct clk_init_data init; + struct clk_init_data init = {}; struct clk *clk; clk_mux = kzalloc(sizeof(*clk_mux), GFP_KERNEL); -- 1.8.1.1.dirty

5 years, 7 months

2
3
0 0

[PATCH] ACPI: GED: add support for _Exx / _Lxx handler methods

by Ard Biesheuvel

Per the ACPI spec, interrupts in the range [0, 255] may be handled in AML using individual methods whose naming is based on the format _Exx or _Lxx, where xx is the hex representation of the interrupt index. Add support for this missing feature to our ACPI GED driver. Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net> Cc: Len Brown <lenb(a)kernel.org> Cc: linux-acpi(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # v4.9+ Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- drivers/acpi/evged.c | 22 +++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c index aba0d0027586..6d7a522952bf 100644 --- a/drivers/acpi/evged.c +++ b/drivers/acpi/evged.c @@ -79,6 +79,8 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares, struct resource r; struct acpi_resource_irq *p = &ares->data.irq; struct acpi_resource_extended_irq *pext = &ares->data.extended_irq; + char ev_name[5]; + u8 trigger; if (ares->type == ACPI_RESOURCE_TYPE_END_TAG) return AE_OK; @@ -87,14 +89,28 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares, dev_err(dev, "unable to parse IRQ resource\n"); return AE_ERROR; } - if (ares->type == ACPI_RESOURCE_TYPE_IRQ) + if (ares->type == ACPI_RESOURCE_TYPE_IRQ) { gsi = p->interrupts[0]; - else + trigger = p->triggering; + } else { gsi = pext->interrupts[0]; + trigger = p->triggering; + } irq = r.start; - if (ACPI_FAILURE(acpi_get_handle(handle, "_EVT", &evt_handle))) { + switch (gsi) { + case 0 ... 255: + sprintf(ev_name, "_%c%02hhX", + trigger == ACPI_EDGE_SENSITIVE ? 'E' : 'L', gsi); + + if (ACPI_SUCCESS(acpi_get_handle(handle, ev_name, &evt_handle))) + break; + /* fall through */ + default: + if (ACPI_SUCCESS(acpi_get_handle(handle, "_EVT", &evt_handle))) + break; + dev_err(dev, "cannot locate _EVT method\n"); return AE_ERROR; } -- 2.17.1

5 years, 7 months

2
3
0 0

stable-rc/linux-5.6.y boot: 131 boots: 1 failed, 122 passed with 6 offline, 2 untried/unknown (v5.6.14-121-g8f40203f4915)

by kernelci.org bot

****************************************** * WARNING: Boot tests are now deprecated * ****************************************** As kernelci.org is expanding its functional testing capabilities, the concept of boot testing is now deprecated. Boot results are scheduled to be dropped on *5th June 2020*. The full schedule for boot tests deprecation is available on this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238 The new equivalent is the *baseline* test suite which also runs sanity checks using dmesg and bootrr: https://github.com/kernelci/bootrr See the *baseline results for this kernel revision* on this page: https://kernelci.org/test/job/stable-rc/branch/linux-5.6.y/kernel/v5.6.14-1… ------------------------------------------------------------------------------- stable-rc/linux-5.6.y boot: 131 boots: 1 failed, 122 passed with 6 offline, 2 untried/unknown (v5.6.14-121-g8f40203f4915) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.6.y/kernel/v5.6.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.6.y/kernel/v5.6.14-121-… Tree: stable-rc Branch: linux-5.6.y Git Describe: v5.6.14-121-g8f40203f4915 Git Commit: 8f40203f49158f3292f524ed280268758f8c9f30 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 88 unique boards, 23 SoC families, 20 builds out of 200 Boot Failure Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 7 months

1
0
0 0

stable-rc/linux-4.19.y boot: 139 boots: 2 failed, 125 passed with 7 offline, 5 untried/unknown (v4.19.124-77-g0708fb235b9c)

by kernelci.org bot

****************************************** * WARNING: Boot tests are now deprecated * ****************************************** As kernelci.org is expanding its functional testing capabilities, the concept of boot testing is now deprecated. Boot results are scheduled to be dropped on *5th June 2020*. The full schedule for boot tests deprecation is available on this GitHub issue: https://github.com/kernelci/kernelci-backend/issues/238 The new equivalent is the *baseline* test suite which also runs sanity checks using dmesg and bootrr: https://github.com/kernelci/bootrr See the *baseline results for this kernel revision* on this page: https://kernelci.org/test/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.12… ------------------------------------------------------------------------------- stable-rc/linux-4.19.y boot: 139 boots: 2 failed, 125 passed with 7 offline, 5 untried/unknown (v4.19.124-77-g0708fb235b9c) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.124-7… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.124-77-g0708fb235b9c Git Commit: 0708fb235b9c82f3d983e90bdc1a11227512055b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 80 unique boards, 22 SoC families, 19 builds out of 206 Boot Regressions Detected: arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: failing since 1 day (last pass: v4.19.123-81-gff1170bc0ae9 - first fail: v4.19.124) dm365evm,legacy: lab-baylibre-seattle: failing since 1 day (last pass: v4.19.123-81-gff1170bc0ae9 - first fail: v4.19.124) omap2plus_defconfig: gcc-8: omap3-beagle-xm: lab-baylibre: new failure (last pass: v4.19.123-81-gff1170bc0ae9) qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 13 days (last pass: v4.19.122 - first fail: v4.19.122-48-g92ba0b6b33ad) sama5_defconfig: gcc-8: at91-sama5d4_xplained: lab-baylibre: failing since 74 days (last pass: v4.19.108-87-g624c124960e8 - first fail: v4.19.109) Boot Failures Detected: arm: omap2plus_defconfig: gcc-8: omap3-beagle-xm: 1 failed lab sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror