July 2019 - Linux-stable-mirror

[patch 15/38] resource: fix locking in find_next_iomem_res()

by akpm＠linux-foundation.org

From: Nadav Amit <namit(a)vmware.com> Subject: resource: fix locking in find_next_iomem_res() Since resources can be removed, locking should ensure that the resource is not removed while accessing it. However, find_next_iomem_res() does not hold the lock while copying the data of the resource. Keep holding the lock while the data is copied. While at it, change the return value to a more informative value. It is disregarded by the callers. [akpm(a)linux-foundation.org: fix find_next_iomem_res() documentation] Link: http://lkml.kernel.org/r/20190613045903.4922-2-namit@vmware.com Fixes: ff3cc952d3f00 ("resource: Add remove_resource interface") Signed-off-by: Nadav Amit <namit(a)vmware.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Cc: Borislav Petkov <bp(a)suse.de> Cc: Toshi Kani <toshi.kani(a)hpe.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/resource.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) --- a/kernel/resource.c~resource-fix-locking-in-find_next_iomem_res +++ a/kernel/resource.c @@ -326,7 +326,7 @@ EXPORT_SYMBOL(release_resource); * * If a resource is found, returns 0 and @*res is overwritten with the part * of the resource that's within [@start..@end]; if none is found, returns - * -1 or -EINVAL for other invalid parameters. + * -ENODEV. Returns -EINVAL for invalid parameters. * * This function walks the whole tree and not just first level children * unless @first_lvl is true. @@ -365,16 +365,16 @@ static int find_next_iomem_res(resource_ break; } - read_unlock(&resource_lock); - if (!p) - return -1; + if (p) { + /* copy data */ + res->start = max(start, p->start); + res->end = min(end, p->end); + res->flags = p->flags; + res->desc = p->desc; + } - /* copy data */ - res->start = max(start, p->start); - res->end = min(end, p->end); - res->flags = p->flags; - res->desc = p->desc; - return 0; + read_unlock(&resource_lock); + return p ? 0 : -ENODEV; } static int __walk_iomem_res_desc(resource_size_t start, resource_size_t end, _

5 years, 5 months

1
0
0 0

[PATCH] cifs: flush before set-info if we have writeable handles

by Ronnie Sahlberg

Servers can defer destaging any data and updating the mtime until close(). This means that if we do a setinfo to modify the mtime while other handles are open for write the server may overwrite our setinfo timestamps when if flushes the file on close() of the writeable handle. To solve this we add an explicit flush when the mtime is about to be updated. This fixes "cp -p" to preserve mtime when copying a file onto an SMB2 share. CC: Stable <stable(a)vger.kernel.org> Signed-off-by: Ronnie Sahlberg <lsahlber(a)redhat.com> --- fs/cifs/inode.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c index 1bffe029fb66..56ca4b8ccaba 100644 --- a/fs/cifs/inode.c +++ b/fs/cifs/inode.c @@ -2406,6 +2406,8 @@ cifs_setattr_nounix(struct dentry *direntry, struct iattr *attrs) struct inode *inode = d_inode(direntry); struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb); struct cifsInodeInfo *cifsInode = CIFS_I(inode); + struct cifsFileInfo *wfile; + struct cifs_tcon *tcon; char *full_path = NULL; int rc = -EACCES; __u32 dosattr = 0; @@ -2452,6 +2454,20 @@ cifs_setattr_nounix(struct dentry *direntry, struct iattr *attrs) mapping_set_error(inode->i_mapping, rc); rc = 0; + if (attrs->ia_valid & ATTR_MTIME) { + rc = cifs_get_writable_file(cifsInode, false, &wfile); + if (!rc) { + tcon = tlink_tcon(wfile->tlink); + rc = tcon->ses->server->ops->flush(xid, tcon, &wfile->fid); + cifsFileInfo_put(wfile); + if (rc) + return rc; + } else if (rc != -EBADF) + return rc; + else + rc = 0; + } + if (attrs->ia_valid & ATTR_SIZE) { rc = cifs_set_file_size(inode, attrs, xid, full_path); if (rc != 0) -- 2.13.6

5 years, 5 months

1
0
0 0

+ mm-compaction-avoid-100%-cpu-usage-during-compaction-when-a-task-is-killed.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: compaction: avoid 100% CPU usage during compaction when a task is killed has been added to the -mm tree. Its filename is mm-compaction-avoid-100%-cpu-usage-during-compaction-when-a-task-is-killed.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-compaction-avoid-100%25-cpu-usa… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-compaction-avoid-100%25-cpu-usa… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Mel Gorman <mgorman(a)techsingularity.net> Subject: mm: compaction: avoid 100% CPU usage during compaction when a task is killed "howaboutsynergy" reported via kernel buzilla number 204165 that compact_zone_order was consuming 100% CPU during a stress test for prolonged periods of time. Specifically the following command, which should exit in 10 seconds, was taking an excessive time to finish while the CPU was pegged at 100%. stress -m 220 --vm-bytes 1000000000 --timeout 10 Tracing indicated a pattern as follows stress-3923 [007] 519.106208: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106212: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106216: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106219: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106223: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106227: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106231: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106235: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106238: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 stress-3923 [007] 519.106242: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0 Note that compaction is entered in rapid succession while scanning and isolating nothing. The problem is that when a task that is compacting receives a fatal signal, it retries indefinitely instead of exiting while making no progress as a fatal signal is pending. It's not easy to trigger this condition although enabling zswap helps on the basis that the timing is altered. A very small window has to be hit for the problem to occur (signal delivered while compacting and isolating a PFN for migration that is not aligned to SWAP_CLUSTER_MAX). This was reproduced locally -- 16G single socket system, 8G swap, 30% zswap configured, vm-bytes 22000000000 using Colin Kings stress-ng implementation from github running in a loop until the problem hits). Tracing recorded the problem occurring almost 200K times in a short window. With this patch, the problem hit 4 times but the task existed normally instead of consuming CPU. This problem has existed for some time but it was made worse by cf66f0700c8f ("mm, compaction: do not consider a need to reschedule as contention"). Before that commit, if the same condition was hit then locks would be quickly contended and compaction would exit that way. The reporter's real name is unknown. This was caught and repaired due to their testing and tracing. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204165 Link: http://lkml.kernel.org/r/20190718085708.GE24383@techsingularity.net Fixes: cf66f0700c8f ("mm, compaction: do not consider a need to reschedule as contention") Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Reported-by: <howaboutsynergy(a)protonmail.com> Tested-by: <howaboutsynergy(a)protonmail.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> [5.1+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/compaction.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/mm/compaction.c~mm-compaction-avoid-100%-cpu-usage-during-compaction-when-a-task-is-killed +++ a/mm/compaction.c @@ -842,13 +842,15 @@ isolate_migratepages_block(struct compac /* * Periodically drop the lock (if held) regardless of its - * contention, to give chance to IRQs. Abort async compaction - * if contended. + * contention, to give chance to IRQs. Abort completely if + * a fatal signal is pending. */ if (!(low_pfn % SWAP_CLUSTER_MAX) && compact_unlock_should_abort(&pgdat->lru_lock, - flags, &locked, cc)) - break; + flags, &locked, cc)) { + low_pfn = 0; + goto fatal_pending; + } if (!pfn_valid_within(low_pfn)) goto isolate_fail; @@ -1060,6 +1062,7 @@ isolate_abort: trace_mm_compaction_isolate_migratepages(start_pfn, low_pfn, nr_scanned, nr_isolated); +fatal_pending: cc->total_migrate_scanned += nr_scanned; if (nr_isolated) count_compact_events(COMPACTISOLATED, nr_isolated); _ Patches currently in -mm which might be from mgorman(a)techsingularity.net are mm-compaction-avoid-100%-cpu-usage-during-compaction-when-a-task-is-killed.patch

5 years, 5 months

1
0
0 0

+ mm-migrate-fix-reference-check-race-between-__find_get_block-and-migration.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: migrate: fix reference check race between __find_get_block() and migration has been added to the -mm tree. Its filename is mm-migrate-fix-reference-check-race-between-__find_get_block-and-migration.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-migrate-fix-reference-check-rac… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-migrate-fix-reference-check-rac… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Jan Kara <jack(a)suse.cz> Subject: mm: migrate: fix reference check race between __find_get_block() and migration buffer_migrate_page_norefs() can race with bh users in the following way: CPU1 CPU2 buffer_migrate_page_norefs() buffer_migrate_lock_buffers() checks bh refs spin_unlock(&mapping->private_lock) __find_get_block() spin_lock(&mapping->private_lock) grab bh ref spin_unlock(&mapping->private_lock) move page do bh work This can result in various issues like lost updates to buffers (i.e. metadata corruption) or use after free issues for the old page. This patch closes the race by holding mapping->private_lock while the mapping is being moved to a new page. Ordinarily, a reference can be taken outside of the private_lock using the per-cpu BH LRU but the references are checked and the LRU invalidated if necessary. The private_lock is held once the references are known so the buffer lookup slow path will spin on the private_lock. Between the page lock and private_lock, it should be impossible for other references to be acquired and updates to happen during the migration. A user had reported data corruption issues on a distribution kernel with a similar page migration implementation as mainline. The data corruption could not be reproduced with this patch applied. A small number of migration-intensive tests were run and no performance problems were noted. [mgorman(a)techsingularity.net: Changelog, removed tracing] Link: http://lkml.kernel.org/r/20190718090238.GF24383@techsingularity.net Fixes: 89cb0888ca14 "mm: migrate: provide buffer_migrate_page_norefs()" Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Cc: <stable(a)vger.kernel.org> [5.0+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/migrate.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/mm/migrate.c~mm-migrate-fix-reference-check-race-between-__find_get_block-and-migration +++ a/mm/migrate.c @@ -768,12 +768,12 @@ recheck_buffers: } bh = bh->b_this_page; } while (bh != head); - spin_unlock(&mapping->private_lock); if (busy) { if (invalidated) { rc = -EAGAIN; goto unlock_buffers; } + spin_unlock(&mapping->private_lock); invalidate_bh_lrus(); invalidated = true; goto recheck_buffers; @@ -806,6 +806,8 @@ recheck_buffers: rc = MIGRATEPAGE_SUCCESS; unlock_buffers: + if (check_refs) + spin_unlock(&mapping->private_lock); bh = head; do { unlock_buffer(bh); _ Patches currently in -mm which might be from jack(a)suse.cz are mm-migrate-fix-reference-check-race-between-__find_get_block-and-migration.patch

5 years, 5 months

1
0
0 0

+ mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker has been added to the -mm tree. Its filename is mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-vmscan-check-if-mem-cgroup-is-d… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-vmscan-check-if-mem-cgroup-is-d… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Yang Shi <yang.shi(a)linux.alibaba.com> Subject: mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker Shakeel Butt reported premature oom on kernel with "cgroup_disable=memory" since mem_cgroup_is_root() returns false even though memcg is actually NULL. The drop_caches is also broken. It is because aeed1d325d42 ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()") removed the !memcg check before !mem_cgroup_is_root(). And, surprisingly root memcg is allocated even though memory cgroup is disabled by kernel boot parameter. Add mem_cgroup_disabled() check to make reclaimer work as expected. Link: http://lkml.kernel.org/r/1563385526-20805-1-git-send-email-yang.shi@linux.a… Fixes: aeed1d325d42 ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()") Signed-off-by: Yang Shi <yang.shi(a)linux.alibaba.com> Reported-by: Shakeel Butt <shakeelb(a)google.com> Reviewed-by: Shakeel Butt <shakeelb(a)google.com> Reviewed-by: Kirill Tkhai <ktkhai(a)virtuozzo.com> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Roman Gushchin <guro(a)fb.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Qian Cai <cai(a)lca.pw> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> [4.19+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmscan.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/mm/vmscan.c~mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker +++ a/mm/vmscan.c @@ -699,7 +699,14 @@ static unsigned long shrink_slab(gfp_t g unsigned long ret, freed = 0; struct shrinker *shrinker; - if (!mem_cgroup_is_root(memcg)) + /* + * The root memcg might be allocated even though memcg is disabled + * via "cgroup_disable=memory" boot parameter. This could make + * mem_cgroup_is_root() return false, then just run memcg slab + * shrink, but skip global shrink. This may result in premature + * oom. + */ + if (!mem_cgroup_disabled() && !mem_cgroup_is_root(memcg)) return shrink_slab_memcg(gfp_mask, nid, memcg, priority); if (!down_read_trylock(&shrinker_rwsem)) _ Patches currently in -mm which might be from yang.shi(a)linux.alibaba.com are revert-kmemleak-allow-to-coexist-with-fault-injection.patch mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker.patch mm-mempolicy-make-the-behavior-consistent-when-mpol_mf_move-and-mpol_mf_strict-were-specified.patch mm-mempolicy-handle-vma-with-unmovable-pages-mapped-correctly-in-mbind.patch mm-thp-make-transhuge_vma_suitable-available-for-anonymous-thp.patch mm-thp-make-transhuge_vma_suitable-available-for-anonymous-thp-v4.patch mm-thp-fix-false-negative-of-shmem-vmas-thp-eligibility.patch

5 years, 5 months

1
0
0 0

[PATCH 2/4] drm/i915: Use maximum write flush for pwrite_gtt

by Chris Wilson

As recently disovered by forcing big-core (!llc) machines to use the GTT paths, we need our full GTT write flush before manipulating the GTT PTE or else the writes may be directed to the wrong page. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Matthew Auld <matthew.william.auld(a)gmail.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/i915_gem.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index fed0bc421a55..c6ba350e6e4f 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -610,7 +610,8 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj, unsigned int page_length = PAGE_SIZE - page_offset; page_length = remain < page_length ? remain : page_length; if (node.allocated) { - wmb(); /* flush the write before we modify the GGTT */ + /* flush the write before we modify the GGTT */ + intel_gt_flush_ggtt_writes(ggtt->vm.gt); ggtt->vm.insert_page(&ggtt->vm, i915_gem_object_get_dma_address(obj, offset >> PAGE_SHIFT), node.start, I915_CACHE_NONE, 0); @@ -639,8 +640,8 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj, i915_gem_object_unlock_fence(obj, fence); out_unpin: mutex_lock(&i915->drm.struct_mutex); + intel_gt_flush_ggtt_writes(ggtt->vm.gt); if (node.allocated) { - wmb(); ggtt->vm.clear_range(&ggtt->vm, node.start, node.size); remove_mappable_node(&node); } else { -- 2.22.0

5 years, 5 months

2
2
0 0

[PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

by Dhinakaran Pandiyan

A single 32-bit PSR2 training pattern field follows the sixteen element array of PSR table entries in the VBT spec. But, we incorrectly define this PSR2 field for each of the PSR table entries. As a result, the PSR1 training pattern duration for any panel_type != 0 will be parsed incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb version >= 226 will also be wrong. Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: José Roberto de Souza <jose.souza(a)intel.com> Cc: stable(a)vger.kernel.org Cc: stable(a)vger.kernel.org #v5.2 Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183 Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza(a)intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Tested-by: François Guerraz <kubrick(a)fgv6.net> --- drivers/gpu/drm/i915/display/intel_bios.c | 2 +- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index 21501d565327..b416b394b641 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -766,7 +766,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct bdb_header *bdb) } if (bdb->version >= 226) { - u32 wakeup_time = psr_table->psr2_tp2_tp3_wakeup_time; + u32 wakeup_time = psr->psr2_tp2_tp3_wakeup_time; wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3; switch (wakeup_time) { diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h b/drivers/gpu/drm/i915/display/intel_vbt_defs.h index 93f5c9d204d6..09cd37fb0b1c 100644 --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h @@ -481,13 +481,13 @@ struct psr_table { /* TP wake up time in multiple of 100 */ u16 tp1_wakeup_time; u16 tp2_tp3_wakeup_time; - - /* PSR2 TP2/TP3 wakeup time for 16 panels */ - u32 psr2_tp2_tp3_wakeup_time; } __packed; struct bdb_psr { struct psr_table psr_table[16]; + + /* PSR2 TP2/TP3 wakeup time for 16 panels */ + u32 psr2_tp2_tp3_wakeup_time; } __packed; /* -- 2.17.1

5 years, 5 months

2
1
0 0

Global companies Contact List

by rosie.huynh＠autovalidinfo.com

Hi, Hope this note finds you well. We being a global B2B database provider over a decade and a Compliant Certificate Holder for GDPR. I am trying to reach you with potential leads to help you target your marketing capabilities and boost your sales and marketing plans for 2019. IT Decision Makers: CIO, CTO, VP of IT, IT/Technology, Director of IT, IT Managers Etc. Finance: CFO, Chief Accountant, VP of Finance, President of Finance, Controllers, Etc. Marketing: CMO, SVP/VP Marketing, VP Partner Marketing, Director of Marketing Etc. Telecom/Contact Center VP Telecom, Principal Director Telecom, Senior Director Contact Center Etc. HR Decision Makers: Head of HR, Chief HR Officer, SVP HR, Director HR, VP of HR Etc. IT Security CISO, Head of Security, VP of IT Security Etc. And many more titles. We do also have: If you are looking for the right MSPs, MSSPs, ISVs and VARs to partner with. We have a customized list of MSPs, MSSPs, CSPs, VADs, SIs, ISVs and VARs rendering services for Backup and Recovery, Connectivity, Cyber/Email/Network/Cloud Security, IaaS, VoIP, CRM, DaaS, Virtualization, IT Consulting, ERP, PaaS, End Users, Channel Partners, Resellers, OEM Partners, Software Solution and Technology Partners, Services Partners and many more. Please let me know what technology users you would be interested in and I will get back to you with more information regarding the same. Regards, Rosie Huynh Marketing Specialist If you don't want to include yourself in our mailing list, please reply back “Leave Out" in a subject line

5 years, 5 months

1
0
0 0

[PATCH v2 0/7] libnvdimm: Fix async operations and locking

by Dan Williams

Changes since v1 [1]: - Fix an ioctl command corruption regression that manifested as an intermittent failure of the monitor.sh unit test. This is handled in the patch4 prep patch that makes it safe for nd_ioctl() to be re-entrant. (Vishal) - Update the changelog for the driver-core 'lockdep_lock' hack to indicate Greg's non-NAK. [1]: https://lore.kernel.org/lkml/156029554317.419799.1324389595953183385.stgit@… --- The libnvdimm subsystem uses async operations to parallelize device probing operations and to allow sysfs to trigger device_unregister() on deleted namepsaces. A multithreaded stress test of the libnvdimm sysfs interface uncovered a case where device_unregister() is triggered multiple times, and the subsequent investigation uncovered a broken locking scenario. The lack of lockdep coverage for device_lock() stymied the debug. That is, until patch6 "driver-core, libnvdimm: Let device subsystems add local lockdep coverage" solved that with a shadow lock, with lockdep coverage, to mirror device_lock() operations. Given the time saved with shadow-lock debug-hack, patch6 attempts to generalize device_lock() debug facility that might be able to be carried upstream. Patch6 is staged at the end of this fix series in case it is contentious and needs to be dropped. Patch1 "drivers/base: Introduce kill_device()" could be achieved with local libnvdimm infrastructure. However, the existing 'dead' flag in 'struct device_private' aims to solve similar async register/unregister races so the fix in patch2 "libnvdimm/bus: Prevent duplicate device_unregister() calls" can be implemented with existing driver-core infrastructure. Patch3 is a rare lockdep warning that is intermittent based on namespaces racing ahead of the completion of probe of their parent region. It is not related to the other fixes, it just happened to trigger as a result of the async stress test. Patch5 and patch6 address an ABBA deadlock tripped by the stress test. These patches pass the failing stress test and the existing libnvdimm unit tests with CONFIG_PROVE_LOCKING=y and the new "dev->lockdep_mutex" shadow lock with no lockdep warnings. --- Dan Williams (7): drivers/base: Introduce kill_device() libnvdimm/bus: Prevent duplicate device_unregister() calls libnvdimm/region: Register badblocks before namespaces libnvdimm/bus: Prepare the nd_ioctl() path to be re-entrant libnvdimm/bus: Stop holding nvdimm_bus_list_mutex over __nd_ioctl() libnvdimm/bus: Fix wait_nvdimm_bus_probe_idle() ABBA deadlock driver-core, libnvdimm: Let device subsystems add local lockdep coverage drivers/acpi/nfit/core.c | 28 +++-- drivers/acpi/nfit/nfit.h | 24 ++++ drivers/base/core.c | 30 ++++-- drivers/nvdimm/btt_devs.c | 16 +-- drivers/nvdimm/bus.c | 210 ++++++++++++++++++++++++++------------- drivers/nvdimm/core.c | 10 +- drivers/nvdimm/dimm_devs.c | 4 - drivers/nvdimm/namespace_devs.c | 36 +++---- drivers/nvdimm/nd-core.h | 71 +++++++++++++ drivers/nvdimm/pfn_devs.c | 24 ++-- drivers/nvdimm/pmem.c | 4 - drivers/nvdimm/region.c | 24 ++-- drivers/nvdimm/region_devs.c | 12 +- include/linux/device.h | 6 + 14 files changed, 343 insertions(+), 156 deletions(-)

5 years, 5 months

4
9
0 0

[PATCH] drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> On VLV/CHV there is some kind of linkage between the cdclk frequency and the DP link frequency. The spec says: "For DP audio configuration, cdclk frequency shall be set to meet the following requirements: DP Link Frequency(MHz) | Cdclk frequency(MHz) 270 | 320 or higher 162 | 200 or higher" I suspect that would more accurately be expressed as "cdclk >= DP link clock", and in any case we can express it like that in the code because of the limited set of cdclk and link frequencies we support. Without this we can end up in a situation where the cdclk is too low and enabling DP audio will kill the pipe. Happens eg. with 2560x1440 modes where the 266MHz cdclk is sufficient to pump the pixels (241.5 MHz dotclock) but is too low for the DP audio due to the link frequency being 270 MHz. Cc: stable(a)vger.kernel.org Tested-by: Stefan Gottwald <gottwald(a)igel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111149 Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/display/intel_cdclk.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index d0581a1ac243..93b0d190c184 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.c +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c @@ -2262,6 +2262,17 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state) if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9) min_cdclk = max(2 * 96000, min_cdclk); + /* + * "For DP audio configuration, cdclk frequency shall be set to + * meet the following requirements: + * DP Link Frequency(MHz) | Cdclk frequency(MHz) + * 270 | 320 or higher + * 162 | 200 or higher" + */ + if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) && + intel_crtc_has_dp_encoder(crtc_state) && crtc_state->has_audio) + min_cdclk = max(crtc_state->port_clock, min_cdclk); + /* * On Valleyview some DSI panels lose (v|h)sync when the clock is lower * than 320000KHz. -- 2.21.0

5 years, 5 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2019