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

[PATCH 1/8] blk-mq: make sure that correct hctx->next_cpu is set

by Ming Lei

>From commit 20e4d81393196 (blk-mq: simplify queue mapping & schedule with each possisble CPU), one hctx can be mapped from all offline CPUs, then hctx->next_cpu can be set as wrong. This patch fixes this issue by making hctx->next_cpu pointing to the first CPU in hctx->cpumask if all CPUs in hctx->cpumask are offline. Cc: Christian Borntraeger <borntraeger(a)de.ibm.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Stefan Haberland <sth(a)linux.vnet.ibm.com> Fixes: 20e4d81393196 ("blk-mq: simplify queue mapping & schedule with each possisble CPU") Cc: stable(a)vger.kernel.org Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-mq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index f5c7dbcb954f..9b220dc415ac 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2432,6 +2432,8 @@ static void blk_mq_map_swqueue(struct request_queue *q) */ hctx->next_cpu = cpumask_first_and(hctx->cpumask, cpu_online_mask); + if (hctx->next_cpu >= nr_cpu_ids) + hctx->next_cpu = cpumask_first(hctx->cpumask); hctx->next_cpu_batch = BLK_MQ_CPU_WORK_BATCH; } } -- 2.9.5

7 years, 7 months

3
2
0 0

dma-mapping: clear harmful GFP_* flags in common code

by Alexey Brodkin

Hello, May we have e89f5b370153 ("dma-mapping: Don't clear GFP_ZERO in dma_alloc_attrs") back-ported to 4.16 kernel as it fixes: 57bf5a8 ("dma-mapping: clear harmful GFP_* flags in common code"). For more info about introduced problem see this thread: http://lists.infradead.org/pipermail/linux-snps-arc/2018-March/003652.html -Alexey

7 years, 7 months

1
0
0 0

Grüße von Frau Jordanka

by noreply＠parador.es

Nachricht des Absenders: /Guten Morgen, Bitte schämen Sie sich nicht, diese Nachricht zu lesen, weil Sie der beabsichtigte Empfänger sind. Ich habe deine E-Mail-Adresse über ein Verzeichnis gesehen und ich habe dich kontaktiert, weil ich dringend deine Hilfe benötigt habe. Mein Name ist Frau Yordanka Velikova Nencheva. Ich bin 69 Jahre alt und bin rechtmäßig mit dem verstorbenen Herrn Peter Nencheva verheiratet. Ich und mein verstorbener Ehemann waren beide Bürger von Bulgarien, aber wir lebten hier in der Elfenbeinküste in Westafrika seit 28 Jahren. Mein verstorbener Ehemann arbeitete viele Jahre lang als Expatriate hier in der Elfenbeinküste, bevor er bei einem tödlichen Autounfall starb, bei dem er und sein Fahrer hier in der Elfenbeinküste ums Leben kamen. Ich und mein verstorbener Mann waren beide verheiratet, ohne ein eigenes leibliches Kind. Ich habe derzeit eine schwere Brustkrebskrankheit und schreibe diese Nachricht mit Hilfe eines Arztes hier im Krankenhaus in der Elfenbeinküste. Als mein verstorbener Ehemann noch am Leben war, hinterlegte er die Summe von einer Million fünfhunderttausend Euro (1,500,000.00 Euro) bei der Westra Wermlands Sparbank http://www.warbarbank.se/ in Schweden, die er mit der Bank eine Vereinbarung unterzeichnete die Mittel werden für wohltätige Zwecke verwendet, wie z. Hilfe für die mutterlosen Babys, Unterstützung der kirchlichen Aktivitäten und Unterstützung der nicht privilegierten Kinder, ihre Ausbildung fortzusetzen. Mein Mann hat diese Entscheidung für diese karitative Arbeit getroffen, weil wir kein Kind haben, das die Gelder in der schwedischen Bank erbt, und er wurde von einem Waisenhaus in Sofia, Bulgarien, erzogen, weil er keine Familie in Bulgarien hat. Ich kontaktierte Sie heute, weil mein Arzt mich gerade darüber informiert hat, dass meine Brustkrebskrankheit am schlimmsten geworden ist und sie nächste Woche eine schwere / tödliche Krebsoperation durchführen werden, die ich vielleicht nicht überleben würde, weil der Tod tief in meinem Körpersystem gefressen hat. Ich fürchte, wenn ich nächste Woche während meiner Operation sterbe, werden die Gelder in der schwedischen Bank vergessen, weil ich keinen anderen Verwandten habe, der behauptet, dass ich keine Familie meines verstorbenen Ehemannes in Bulgarien finden kann. Hinweis: Ich möchte, dass Sie mir helfen, das Geld auf Ihr eigenes Bankkonto zu überweisen und es auf Ihr Bankkonto zu überweisen. Sie werden 30% (450.000,00 Euro) des Gesamtbetrages für sich selbst als Entschädigung einstreichen und die restlichen 70% (1,50, 000,00 Euro) für die Wohltätigkeitsarbeit in Ihrem Land verwenden. Bitte antworten Sie mir dringend, wenn Sie daran interessiert sind, mir bei dieser Transaktion zu helfen, damit ich Ihnen weitere Einzelheiten zusenden kann, da ich möchte, dass die Mittel vor meiner bevorstehenden Operation nächste Woche überwiesen werden. Mit freundlichen Grüßen, Frau Yordanka Nencheva Velikova/ Parador de Alcañiz [1] [1] http://www.parador.es/de/paradores/parador-de-alcaniz

7 years, 7 months

1
0
0 0

Patch "x86/gart: Exclude GART aperture from vmcore" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/gart: Exclude GART aperture from vmcore to the 4.15-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-gart-exclude-gart-aperture-from-vmcore.patch and it can be found in the queue-4.15 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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Jiri Bohac <jbohac(a)suse.cz> Date: Sat, 6 Jan 2018 02:00:13 +0100 Subject: x86/gart: Exclude GART aperture from vmcore From: Jiri Bohac <jbohac(a)suse.cz> [ Upstream commit 2a3e83c6f96c513f43ce5a8c9034608ea584a255 ] On machines where the GART aperture is mapped over physical RAM /proc/vmcore contains the remapped range and reading it may cause hangs or reboots. In the past, the GART region was added into the resource map, implemented by commit 56dd669a138c ("[PATCH] Insert GART region into resource map") However, inserting the iomem_resource from the early GART code caused resource conflicts with some AGP drivers (bko#72201), which got avoided by reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map"). This revert introduced the /proc/vmcore bug. The vmcore ELF header is either prepared by the kernel (when using the kexec_file_load syscall) or by the kexec userspace (when using the kexec_load syscall). Since we no longer have the GART iomem resource, the userspace kexec has no way of knowing which region to exclude from the ELF header. Changes from v1 of this patch: Instead of excluding the aperture from the ELF header, this patch makes /proc/vmcore return zeroes in the second kernel when attempting to read the aperture region. This is done by reusing the gart_oldmem_pfn_is_ram infrastructure originally intended to exclude XEN balooned memory. This works for both, the kexec_file_load and kexec_load syscalls. [Note that the GART region is the same in the first and second kernels: regardless whether the first kernel fixed up the northbridge/bios setting and mapped the aperture over physical memory, the second kernel finds the northbridge properly configured by the first kernel and the aperture never overlaps with e820 memory because the second kernel has a fake e820 map created from the crashkernel memory regions. Thus, the second kernel keeps the aperture address/size as configured by the first kernel.] register_oldmem_pfn_is_ram can only register one callback and returns an error if the callback has been registered already. Since XEN used to be the only user of this function, it never checks the return value. Now that we have more than one user, I added a WARN_ON just in case agp, XEN, or any other future user of register_oldmem_pfn_is_ram were to step on each other's toes. Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map") Signed-off-by: Jiri Bohac <jbohac(a)suse.cz> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Baoquan He <bhe(a)redhat.com> Cc: Toshi Kani <toshi.kani(a)hpe.com> Cc: David Airlie <airlied(a)linux.ie> Cc: yinghai(a)kernel.org Cc: joro(a)8bytes.org Cc: kexec(a)lists.infradead.org Cc: Borislav Petkov <bp(a)alien8.de> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: Dave Young <dyoung(a)redhat.com> Cc: Vivek Goyal <vgoyal(a)redhat.com> Link: https://lkml.kernel.org/r/20180106010013.73suskgxm7lox7g6@dwarf.suse.cz Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/aperture_64.c | 46 +++++++++++++++++++++++++++++++++++++++++- arch/x86/xen/mmu_hvm.c | 2 - 2 files changed, 46 insertions(+), 2 deletions(-) --- a/arch/x86/kernel/aperture_64.c +++ b/arch/x86/kernel/aperture_64.c @@ -30,6 +30,7 @@ #include <asm/dma.h> #include <asm/amd_nb.h> #include <asm/x86_init.h> +#include <linux/crash_dump.h> /* * Using 512M as goal, in case kexec will load kernel_big @@ -56,6 +57,33 @@ int fallback_aper_force __initdata; int fix_aperture __initdata = 1; +#ifdef CONFIG_PROC_VMCORE +/* + * If the first kernel maps the aperture over e820 RAM, the kdump kernel will + * use the same range because it will remain configured in the northbridge. + * Trying to dump this area via /proc/vmcore may crash the machine, so exclude + * it from vmcore. + */ +static unsigned long aperture_pfn_start, aperture_page_count; + +static int gart_oldmem_pfn_is_ram(unsigned long pfn) +{ + return likely((pfn < aperture_pfn_start) || + (pfn >= aperture_pfn_start + aperture_page_count)); +} + +static void exclude_from_vmcore(u64 aper_base, u32 aper_order) +{ + aperture_pfn_start = aper_base >> PAGE_SHIFT; + aperture_page_count = (32 * 1024 * 1024) << aper_order >> PAGE_SHIFT; + WARN_ON(register_oldmem_pfn_is_ram(&gart_oldmem_pfn_is_ram)); +} +#else +static void exclude_from_vmcore(u64 aper_base, u32 aper_order) +{ +} +#endif + /* This code runs before the PCI subsystem is initialized, so just access the northbridge directly. */ @@ -435,8 +463,16 @@ int __init gart_iommu_hole_init(void) out: if (!fix && !fallback_aper_force) { - if (last_aper_base) + if (last_aper_base) { + /* + * If this is the kdump kernel, the first kernel + * may have allocated the range over its e820 RAM + * and fixed up the northbridge + */ + exclude_from_vmcore(last_aper_base, last_aper_order); + return 1; + } return 0; } @@ -473,6 +509,14 @@ out: return 0; } + /* + * If this is the kdump kernel _and_ the first kernel did not + * configure the aperture in the northbridge, this range may + * overlap with the first kernel's memory. We can't access the + * range through vmcore even though it should be part of the dump. + */ + exclude_from_vmcore(aper_alloc, aper_order); + /* Fix up the north bridges */ for (i = 0; i < amd_nb_bus_dev_ranges[i].dev_limit; i++) { int bus, dev_base, dev_limit; --- a/arch/x86/xen/mmu_hvm.c +++ b/arch/x86/xen/mmu_hvm.c @@ -75,6 +75,6 @@ void __init xen_hvm_init_mmu_ops(void) if (is_pagetable_dying_supported()) pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap; #ifdef CONFIG_PROC_VMCORE - register_oldmem_pfn_is_ram(&xen_oldmem_pfn_is_ram); + WARN_ON(register_oldmem_pfn_is_ram(&xen_oldmem_pfn_is_ram)); #endif } Patches currently in stable-queue which might be from jbohac(a)suse.cz are queue-4.15/x86-gart-exclude-gart-aperture-from-vmcore.patch

7 years, 7 months

1
0
0 0

Patch "watchdog: dw_wdt: add stop watchdog operation" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled watchdog: dw_wdt: add stop watchdog operation to the 4.15-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: watchdog-dw_wdt-add-stop-watchdog-operation.patch and it can be found in the queue-4.15 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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Oleksij Rempel <o.rempel(a)pengutronix.de> Date: Tue, 26 Sep 2017 08:11:22 +0200 Subject: watchdog: dw_wdt: add stop watchdog operation From: Oleksij Rempel <o.rempel(a)pengutronix.de> [ Upstream commit 1bfe8889380890efe4943d125124f5a7b48571b0 ] The only way of stopping the watchdog is by resetting it. Add the watchdog op for stopping the device and reset if a reset line is provided. At same time WDOG_HW_RUNNING should be remove from dw_wdt_start. As commented by Guenter Roeck: dw_wdt sets WDOG_HW_RUNNING in its open function. Result is that the kref_get() in watchdog_open() won't be executed. But then kref_put() in close will be called since the watchdog now does stop. This causes the imbalance. Signed-off-by: Oleksij Rempel <o.rempel(a)pengutronix.de> Cc: Wim Van Sebroeck <wim(a)iguana.be> Cc: Guenter Roeck <linux(a)roeck-us.net> Cc: linux-watchdog(a)vger.kernel.org Reviewed-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim(a)iguana.be> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/watchdog/dw_wdt.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) --- a/drivers/watchdog/dw_wdt.c +++ b/drivers/watchdog/dw_wdt.c @@ -127,14 +127,27 @@ static int dw_wdt_start(struct watchdog_ dw_wdt_set_timeout(wdd, wdd->timeout); - set_bit(WDOG_HW_RUNNING, &wdd->status); - writel(WDOG_CONTROL_REG_WDT_EN_MASK, dw_wdt->regs + WDOG_CONTROL_REG_OFFSET); return 0; } +static int dw_wdt_stop(struct watchdog_device *wdd) +{ + struct dw_wdt *dw_wdt = to_dw_wdt(wdd); + + if (!dw_wdt->rst) { + set_bit(WDOG_HW_RUNNING, &wdd->status); + return 0; + } + + reset_control_assert(dw_wdt->rst); + reset_control_deassert(dw_wdt->rst); + + return 0; +} + static int dw_wdt_restart(struct watchdog_device *wdd, unsigned long action, void *data) { @@ -173,6 +186,7 @@ static const struct watchdog_info dw_wdt static const struct watchdog_ops dw_wdt_ops = { .owner = THIS_MODULE, .start = dw_wdt_start, + .stop = dw_wdt_stop, .ping = dw_wdt_ping, .set_timeout = dw_wdt_set_timeout, .get_timeleft = dw_wdt_get_timeleft, Patches currently in stable-queue which might be from o.rempel(a)pengutronix.de are queue-4.15/watchdog-dw_wdt-add-stop-watchdog-operation.patch

7 years, 7 months

1
0
0 0

Patch "wl1251: check return from call to wl1251_acx_arp_ip_filter" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled wl1251: check return from call to wl1251_acx_arp_ip_filter to the 4.15-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: wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch and it can be found in the queue-4.15 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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 26 Dec 2017 17:33:18 +0000 Subject: wl1251: check return from call to wl1251_acx_arp_ip_filter From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit ac1181c60822292176ab96912208ec9f9819faf8 ] Currently the less than zero error check on ret is incorrect as it is checking a far earlier ret assignment rather than the return from the call to wl1251_acx_arp_ip_filter. Fix this by adding in the missing assginment. Detected by CoverityScan, CID#1164835 ("Logically dead code") Fixes: 204cc5c44fb6 ("wl1251: implement hardware ARP filtering") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ti/wl1251/main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/net/wireless/ti/wl1251/main.c +++ b/drivers/net/wireless/ti/wl1251/main.c @@ -1200,8 +1200,7 @@ static void wl1251_op_bss_info_changed(s WARN_ON(wl->bss_type != BSS_TYPE_STA_BSS); enable = bss_conf->arp_addr_cnt == 1 && bss_conf->assoc; - wl1251_acx_arp_ip_filter(wl, enable, addr); - + ret = wl1251_acx_arp_ip_filter(wl, enable, addr); if (ret < 0) goto out_sleep; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.15/wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch

7 years, 7 months

1
0
0 0

Patch "VFS: close race between getcwd() and d_move()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled VFS: close race between getcwd() and d_move() to the 4.15-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: vfs-close-race-between-getcwd-and-d_move.patch and it can be found in the queue-4.15 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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: NeilBrown <neilb(a)suse.com> Date: Fri, 10 Nov 2017 15:45:41 +1100 Subject: VFS: close race between getcwd() and d_move() From: NeilBrown <neilb(a)suse.com> [ Upstream commit 61647823aa920e395afcce4b57c32afb51456cab ] d_move() will call __d_drop() and then __d_rehash() on the dentry being moved. This creates a small window when the dentry appears to be unhashed. Many tests of d_unhashed() are made under ->d_lock and so are safe from racing with this window, but some aren't. In particular, getcwd() calls d_unlinked() (which calls d_unhashed()) without d_lock protection, so it can race. This races has been seen in practice with lustre, which uses d_move() as part of name lookup. See: https://jira.hpdd.intel.com/browse/LU-9735 It could race with a regular rename(), and result in ENOENT instead of either the 'before' or 'after' name. The race can be demonstrated with a simple program which has two threads, one renaming a directory back and forth while another calls getcwd() within that directory: it should never fail, but does. See: https://patchwork.kernel.org/patch/9455345/ We could fix this race by taking d_lock and rechecking when d_unhashed() reports true. Alternately when can remove the window, which is the approach this patch takes. ___d_drop() is introduce which does *not* clear d_hash.pprev so the dentry still appears to be hashed. __d_drop() calls ___d_drop(), then clears d_hash.pprev. __d_move() now uses ___d_drop() and only clears d_hash.pprev when not rehashing. Signed-off-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/dcache.c | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -468,9 +468,11 @@ static void dentry_lru_add(struct dentry * d_drop() is used mainly for stuff that wants to invalidate a dentry for some * reason (NFS timeouts or autofs deletes). * - * __d_drop requires dentry->d_lock. + * __d_drop requires dentry->d_lock + * ___d_drop doesn't mark dentry as "unhashed" + * (dentry->d_hash.pprev will be LIST_POISON2, not NULL). */ -void __d_drop(struct dentry *dentry) +static void ___d_drop(struct dentry *dentry) { if (!d_unhashed(dentry)) { struct hlist_bl_head *b; @@ -486,12 +488,17 @@ void __d_drop(struct dentry *dentry) hlist_bl_lock(b); __hlist_bl_del(&dentry->d_hash); - dentry->d_hash.pprev = NULL; hlist_bl_unlock(b); /* After this call, in-progress rcu-walk path lookup will fail. */ write_seqcount_invalidate(&dentry->d_seq); } } + +void __d_drop(struct dentry *dentry) +{ + ___d_drop(dentry); + dentry->d_hash.pprev = NULL; +} EXPORT_SYMBOL(__d_drop); void d_drop(struct dentry *dentry) @@ -2386,7 +2393,7 @@ EXPORT_SYMBOL(d_delete); static void __d_rehash(struct dentry *entry) { struct hlist_bl_head *b = d_hash(entry->d_name.hash); - BUG_ON(!d_unhashed(entry)); + hlist_bl_lock(b); hlist_bl_add_head_rcu(&entry->d_hash, b); hlist_bl_unlock(b); @@ -2821,9 +2828,9 @@ static void __d_move(struct dentry *dent write_seqcount_begin_nested(&target->d_seq, DENTRY_D_LOCK_NESTED); /* unhash both */ - /* __d_drop does write_seqcount_barrier, but they're OK to nest. */ - __d_drop(dentry); - __d_drop(target); + /* ___d_drop does write_seqcount_barrier, but they're OK to nest. */ + ___d_drop(dentry); + ___d_drop(target); /* Switch the names.. */ if (exchange) @@ -2835,6 +2842,8 @@ static void __d_move(struct dentry *dent __d_rehash(dentry); if (exchange) __d_rehash(target); + else + target->d_hash.pprev = NULL; /* ... and switch them in the tree */ if (IS_ROOT(dentry)) { Patches currently in stable-queue which might be from neilb(a)suse.com are queue-4.15/staging-lustre-disable-preempt-while-sampling-processor-id.patch queue-4.15/vfs-close-race-between-getcwd-and-d_move.patch

7 years, 7 months

1
0
0 0

Patch "vfb: fix video mode and line_length being set when loaded" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vfb: fix video mode and line_length being set when loaded to the 4.15-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: vfb-fix-video-mode-and-line_length-being-set-when-loaded.patch and it can be found in the queue-4.15 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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: "Pieter \\\"PoroCYon\\\" Sluys" <pcy(a)national.shitposting.agency> Date: Thu, 4 Jan 2018 16:53:50 +0100 Subject: vfb: fix video mode and line_length being set when loaded From: "Pieter \\\"PoroCYon\\\" Sluys" <pcy(a)national.shitposting.agency> [ Upstream commit 7b9faf5df0ac495a1a3d7cdb64921c179f9008ac ] Currently, when loading the vfb module, the newly created fbdev has a line_length of 0, and its video mode would be PSEUDOCOLOR regardless of color depth. (The former could be worked around by calling the FBIOPUT_VSCREENINFO ioctl with having the FBACTIVIATE_FORCE flag set.) This patch automatically sets the line_length correctly, and the video mode is derived from the bit depth now as well. Thanks to Geert Uytterhoeven for confirming the bug and helping me with the patch. Output of `fbset -i' before the patch: mode "1366x768-60" # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz geometry 1366 768 1366 768 32 timings 13806 120 10 14 3 32 5 rgba 8/0,8/8,8/16,8/24 endmode Frame buffer device information: Name : Virtual FB Address : 0xffffaa1405d85000 Size : 4196352 Type : PACKED PIXELS Visual : PSEUDOCOLOR XPanStep : 1 YPanStep : 1 YWrapStep : 1 LineLength : 0 <-- note this Accelerator : No After: mode "1366x768-60" # D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz geometry 1366 768 1366 768 32 timings 13806 120 10 14 3 32 5 rgba 8/0,8/8,8/16,8/24 endmode Frame buffer device information: Name : Virtual FB Address : 0xffffaa1405d85000 Size : 4196352 Type : PACKED PIXELS Visual : TRUECOLOR XPanStep : 1 YPanStep : 1 YWrapStep : 1 LineLength : 5464 Accelerator : No Signed-off-by: "Pieter \"PoroCYon\" Sluys" <pcy(a)national.shitposting.agency> Reviewed-by: Geert Uytterhoeven <geert(a)linux-m68k.org> [b.zolnierkie: minor fixups] Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/vfb.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) --- a/drivers/video/fbdev/vfb.c +++ b/drivers/video/fbdev/vfb.c @@ -239,8 +239,23 @@ static int vfb_check_var(struct fb_var_s */ static int vfb_set_par(struct fb_info *info) { + switch (info->var.bits_per_pixel) { + case 1: + info->fix.visual = FB_VISUAL_MONO01; + break; + case 8: + info->fix.visual = FB_VISUAL_PSEUDOCOLOR; + break; + case 16: + case 24: + case 32: + info->fix.visual = FB_VISUAL_TRUECOLOR; + break; + } + info->fix.line_length = get_line_length(info->var.xres_virtual, info->var.bits_per_pixel); + return 0; } @@ -450,6 +465,8 @@ static int vfb_probe(struct platform_dev goto err2; platform_set_drvdata(dev, info); + vfb_set_par(info); + fb_info(info, "Virtual frame buffer device, using %ldK of video memory\n", videomemorysize >> 10); return 0; Patches currently in stable-queue which might be from pcy(a)national.shitposting.agency are queue-4.15/vfb-fix-video-mode-and-line_length-being-set-when-loaded.patch

7 years, 7 months

1
0
0 0

Patch "tty: n_gsm: Allow ADM response in addition to UA for control dlci" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: n_gsm: Allow ADM response in addition to UA for control dlci to the 4.15-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: tty-n_gsm-allow-adm-response-in-addition-to-ua-for-control-dlci.patch and it can be found in the queue-4.15 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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Tony Lindgren <tony(a)atomide.com> Date: Wed, 3 Jan 2018 10:18:03 -0800 Subject: tty: n_gsm: Allow ADM response in addition to UA for control dlci From: Tony Lindgren <tony(a)atomide.com> [ Upstream commit ea3d8465ab9b3e01be329ac5195970a84bef76c5 ] Some devices have the control dlci stay in ADM mode instead of the UA mode. This can seen at least on droid 4 when trying to open the ts 27.010 mux port. Enabling n_gsm debug mode shows the control dlci always respond with DM to SABM instead of UA: # modprobe n_gsm debug=0xff # ldattach -d GSM0710 /dev/ttyS0 & gsmld_output: 00000000: f9 03 3f 01 1c f9 --> 0) C: SABM(P) gsmld_receive: 00000000: f9 03 1f 01 36 f9 <-- 0) C: DM(P) ... $ minicom -D /dev/gsmtty1 minicom: cannot open /dev/gsmtty1: No error information $ strace minicom -D /dev/gsmtty1 ... open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT Note that this is different issue from other n_gsm -EL2HLT issues such as timeouts when the control dlci does not respond at all. The ADM mode seems to be a quite common according to "RF Wireless World" article "GSM Issue-UE sends SABM and gets a DM response instead of UA response": This issue is most commonly observed in GSM networks where in UE sends SABM and expects network to send UA response but it ends up receiving DM response from the network. SABM stands for Set asynchronous balanced mode, UA stands for Unnumbered Acknowledge and DA stands for Disconnected Mode. An RLP entity can be in one of two modes: - Asynchronous Balanced Mode (ABM) - Asynchronous Disconnected Mode (ADM) Currently Linux kernel closes the control dlci after several retries in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce error code -EL2HLT when trying to open them as the closing of control dlci has already set gsm->dead. Let's fix the issue by allowing control dlci stay in ADM mode after the retries so the /dev/gsmtty ports can be opened and used. It seems that it might take several attempts to get any response from the control dlci, so it's best to allow ADM mode only after the SABM retries are done. Note that for droid 4 additional patches are needed to mux the ttyS0 pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also needed to use n_gsm. And the mdm6600 modem needs to be powered on. Cc: linux-serial(a)vger.kernel.org Cc: Alan Cox <alan(a)llwyncelyn.cymru> Cc: Jiri Prchal <jiri.prchal(a)aksignal.cz> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Marcel Partap <mpartap(a)gmx.net> Cc: Michael Scott <michael.scott(a)linaro.org> Cc: Peter Hurley <peter(a)hurleysoftware.com> Cc: Russ Gorby <russ.gorby(a)intel.com> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: Sebastian Reichel <sre(a)kernel.org> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/n_gsm.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -1451,6 +1451,10 @@ static void gsm_dlci_open(struct gsm_dlc * in which case an opening port goes back to closed and a closing port * is simply put into closed state (any further frames from the other * end will get a DM response) + * + * Some control dlci can stay in ADM mode with other dlci working just + * fine. In that case we can just keep the control dlci open after the + * DLCI_OPENING retries time out. */ static void gsm_dlci_t1(struct timer_list *t) @@ -1464,8 +1468,15 @@ static void gsm_dlci_t1(struct timer_lis if (dlci->retries) { gsm_command(dlci->gsm, dlci->addr, SABM|PF); mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100); - } else + } else if (!dlci->addr && gsm->control == (DM | PF)) { + if (debug & 8) + pr_info("DLCI %d opening in ADM mode.\n", + dlci->addr); + gsm_dlci_open(dlci); + } else { gsm_dlci_close(dlci); + } + break; case DLCI_CLOSING: dlci->retries--; @@ -1483,8 +1494,8 @@ static void gsm_dlci_t1(struct timer_lis * @dlci: DLCI to open * * Commence opening a DLCI from the Linux side. We issue SABM messages - * to the modem which should then reply with a UA, at which point we - * will move into open state. Opening is done asynchronously with retry + * to the modem which should then reply with a UA or ADM, at which point + * we will move into open state. Opening is done asynchronously with retry * running off timers and the responses. */ Patches currently in stable-queue which might be from tony(a)atomide.com are queue-4.15/tty-n_gsm-allow-adm-response-in-addition-to-ua-for-control-dlci.patch

7 years, 7 months

1
0
0 0

Patch "uio_hv_generic: check that host supports monitor page" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled uio_hv_generic: check that host supports monitor page to the 4.15-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: uio_hv_generic-check-that-host-supports-monitor-page.patch and it can be found in the queue-4.15 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 foo@baz Mon Apr 9 10:16:32 CEST 2018 From: Stephen Hemminger <stephen(a)networkplumber.org> Date: Tue, 9 Jan 2018 12:57:31 -0800 Subject: uio_hv_generic: check that host supports monitor page From: Stephen Hemminger <stephen(a)networkplumber.org> [ Upstream commit 06028d15177a1b406b7b075ea47c6a352732f23a ] In order for userspace application to signal host, it needs the host to support the monitor page property. Check for the flag and fail if this is not supported. Signed-off-by: Stephen Hemminger <sthemmin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/uio/uio_hv_generic.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -124,6 +124,13 @@ hv_uio_probe(struct hv_device *dev, if (ret) goto fail; + /* Communicating with host has to be via shared memory not hypercall */ + if (!dev->channel->offermsg.monitor_allocated) { + dev_err(&dev->device, "vmbus channel requires hypercall\n"); + ret = -ENOTSUPP; + goto fail_close; + } + dev->channel->inbound.ring_buffer->interrupt_mask = 1; set_channel_read_mode(dev->channel, HV_CALL_DIRECT); Patches currently in stable-queue which might be from stephen(a)networkplumber.org are queue-4.15/uio_hv_generic-check-that-host-supports-monitor-page.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror