November 2018 - Linux-stable-mirror

[PATCH] x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()

by Dan Williams

Commit f77084d96355 "x86/mm/pat: Disable preemption around __flush_tlb_all()" addressed a case where __flush_tlb_all() is called without preemption being disabled. It also left a warning to catch other cases where preemption is not disabled. That warning triggers for the memory hotplug path which is also used for persistent memory enabling: WARNING: CPU: 35 PID: 911 at ./arch/x86/include/asm/tlbflush.h:460 RIP: 0010:__flush_tlb_all+0x1b/0x3a [..] Call Trace: phys_pud_init+0x29c/0x2bb kernel_physical_mapping_init+0xfc/0x219 init_memory_mapping+0x1a5/0x3b0 arch_add_memory+0x2c/0x50 devm_memremap_pages+0x3aa/0x610 pmem_attach_disk+0x585/0x700 [nd_pmem] Andy wondered why a path that can sleep was using __flush_tlb_all() [1] and Dave confirmed the expectation for TLB flush is for modifying / invalidating existing pte entries, but not initial population [2]. Drop the usage of __flush_tlb_all() in phys_{p4d,pud,pmd}_init() on the expectation that this path is only ever populating empty entries for the linear map. Note, at linear map teardown time there is a call to the all-cpu flush_tlb_all() to invalidate the removed mappings. [1]: https://lore.kernel.org/patchwork/patch/1009434/#1193941 [2]: https://lore.kernel.org/patchwork/patch/1009434/#1194540 Fixes: f77084d96355 ("x86/mm/pat: Disable preemption around __flush_tlb_all()") Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: <stable(a)vger.kernel.org> Reported-by: Andy Lutomirski <luto(a)kernel.org> Suggested-by: Dave Hansen <dave.hansen(a)linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- arch/x86/mm/init_64.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index 5fab264948c2..de95db8ac52f 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -584,7 +584,6 @@ phys_pud_init(pud_t *pud_page, unsigned long paddr, unsigned long paddr_end, paddr_end, page_size_mask, prot); - __flush_tlb_all(); continue; } /* @@ -627,7 +626,6 @@ phys_pud_init(pud_t *pud_page, unsigned long paddr, unsigned long paddr_end, pud_populate(&init_mm, pud, pmd); spin_unlock(&init_mm.page_table_lock); } - __flush_tlb_all(); update_page_count(PG_LEVEL_1G, pages); @@ -668,7 +666,6 @@ phys_p4d_init(p4d_t *p4d_page, unsigned long paddr, unsigned long paddr_end, paddr_last = phys_pud_init(pud, paddr, paddr_end, page_size_mask); - __flush_tlb_all(); continue; } @@ -680,7 +677,6 @@ phys_p4d_init(p4d_t *p4d_page, unsigned long paddr, unsigned long paddr_end, p4d_populate(&init_mm, p4d, pud); spin_unlock(&init_mm.page_table_lock); } - __flush_tlb_all(); return paddr_last; } @@ -733,8 +729,6 @@ kernel_physical_mapping_init(unsigned long paddr_start, if (pgd_changed) sync_global_pgds(vaddr_start, vaddr_end - 1); - __flush_tlb_all(); - return paddr_last; }

5 years, 11 months

4
6
0 0

[merged] scripts-spdxcheck-make-python3-compliant.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: scripts/spdxcheck.py: make python3 compliant has been removed from the -mm tree. Its filename was scripts-spdxcheck-make-python3-compliant.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Subject: scripts/spdxcheck.py: make python3 compliant Without this change the following happens when using Python3 (3.6.6): $ echo "GPL-2.0" | python3 scripts/spdxcheck.py - FAIL: 'str' object has no attribute 'decode' Traceback (most recent call last): File "scripts/spdxcheck.py", line 253, in <module> parser.parse_lines(sys.stdin, args.maxlines, '-') File "scripts/spdxcheck.py", line 171, in parse_lines line = line.decode(locale.getpreferredencoding(False), errors='ignore') AttributeError: 'str' object has no attribute 'decode' So as the line is already a string, there is no need to decode it and the line can be dropped. /usr/bin/python on Arch is Python 3. So this would indeed be worth going into 4.19. Link: http://lkml.kernel.org/r/20181023070802.22558-1-u.kleine-koenig@pengutronix… Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Joe Perches <joe(a)perches.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- scripts/spdxcheck.py | 1 - 1 file changed, 1 deletion(-) --- a/scripts/spdxcheck.py~scripts-spdxcheck-make-python3-compliant +++ a/scripts/spdxcheck.py @@ -168,7 +168,6 @@ class id_parser(object): self.curline = 0 try: for line in fd: - line = line.decode(locale.getpreferredencoding(False), errors='ignore') self.curline += 1 if self.curline > maxlines: break _ Patches currently in -mm which might be from u.kleine-koenig(a)pengutronix.de are

5 years, 11 months

1
0
0 0

[merged] ubsan-dont-mark-__ubsan_handle_builtin_unreachable-as-noreturn.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: lib/ubsan.c: don't mark __ubsan_handle_builtin_unreachable as noreturn has been removed from the -mm tree. Its filename was ubsan-dont-mark-__ubsan_handle_builtin_unreachable-as-noreturn.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Arnd Bergmann <arnd(a)arndb.de> Subject: lib/ubsan.c: don't mark __ubsan_handle_builtin_unreachable as noreturn gcc-8 complains about the prototype for this function: lib/ubsan.c:432:1: error: ignoring attribute 'noreturn' in declaration of a built-in function '__ubsan_handle_builtin_unreachable' because it conflicts with attribute 'const' [-Werror=attributes] This is actually a GCC's bug. In GCC internals __ubsan_handle_builtin_unreachable() declared with both 'noreturn' and 'const' attributes instead of only 'noreturn': https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84210 Workaround this by removing the noreturn attribute. [aryabinin: add information about GCC bug in changelog] Link: http://lkml.kernel.org/r/20181107144516.4587-1-aryabinin@virtuozzo.com Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Acked-by: Olof Johansson <olof(a)lixom.net> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/ubsan.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/lib/ubsan.c~ubsan-dont-mark-__ubsan_handle_builtin_unreachable-as-noreturn +++ a/lib/ubsan.c @@ -427,8 +427,7 @@ void __ubsan_handle_shift_out_of_bounds( EXPORT_SYMBOL(__ubsan_handle_shift_out_of_bounds); -void __noreturn -__ubsan_handle_builtin_unreachable(struct unreachable_data *data) +void __ubsan_handle_builtin_unreachable(struct unreachable_data *data) { unsigned long flags; _ Patches currently in -mm which might be from arnd(a)arndb.de are vfs-replace-current_kernel_time64-with-ktime-equivalent.patch

5 years, 11 months

1
0
0 0

[merged] ocfs2-free-up-write-context-when-direct-io-failed.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ocfs2: free up write context when direct IO failed has been removed from the -mm tree. Its filename was ocfs2-free-up-write-context-when-direct-io-failed.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Wengang Wang <wen.gang.wang(a)oracle.com> Subject: ocfs2: free up write context when direct IO failed The write context should also be freed even when direct IO failed. Otherwise a memory leak is introduced and entries remain in oi->ip_unwritten_list causing the following BUG later in unlink path: ERROR: bug expression: !list_empty(&oi->ip_unwritten_list) ERROR: Clear inode of 215043, inode has unwritten extents ... Call Trace: ? __set_current_blocked+0x42/0x68 ocfs2_evict_inode+0x91/0x6a0 [ocfs2] ? bit_waitqueue+0x40/0x33 evict+0xdb/0x1af iput+0x1a2/0x1f7 do_unlinkat+0x194/0x28f SyS_unlinkat+0x1b/0x2f do_syscall_64+0x79/0x1ae entry_SYSCALL_64_after_hwframe+0x151/0x0 This patch also logs, with frequency limit, direct IO failures. Link: http://lkml.kernel.org/r/20181102170632.25921-1-wen.gang.wang@oracle.com Signed-off-by: Wengang Wang <wen.gang.wang(a)oracle.com> Reviewed-by: Junxiao Bi <junxiao.bi(a)oracle.com> Reviewed-by: Changwei Ge <ge.changwei(a)h3c.com> Reviewed-by: Joseph Qi <jiangqi903(a)gmail.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/aops.c | 12 ++++++++++-- fs/ocfs2/cluster/masklog.h | 9 +++++++++ 2 files changed, 19 insertions(+), 2 deletions(-) --- a/fs/ocfs2/aops.c~ocfs2-free-up-write-context-when-direct-io-failed +++ a/fs/ocfs2/aops.c @@ -2411,8 +2411,16 @@ static int ocfs2_dio_end_io(struct kiocb /* this io's submitter should not have unlocked this before we could */ BUG_ON(!ocfs2_iocb_is_rw_locked(iocb)); - if (bytes > 0 && private) - ret = ocfs2_dio_end_io_write(inode, private, offset, bytes); + if (bytes <= 0) + mlog_ratelimited(ML_ERROR, "Direct IO failed, bytes = %lld", + (long long)bytes); + if (private) { + if (bytes > 0) + ret = ocfs2_dio_end_io_write(inode, private, offset, + bytes); + else + ocfs2_dio_free_write_ctx(inode, private); + } ocfs2_iocb_clear_rw_locked(iocb); --- a/fs/ocfs2/cluster/masklog.h~ocfs2-free-up-write-context-when-direct-io-failed +++ a/fs/ocfs2/cluster/masklog.h @@ -178,6 +178,15 @@ do { \ ##__VA_ARGS__); \ } while (0) +#define mlog_ratelimited(mask, fmt, ...) \ +do { \ + static DEFINE_RATELIMIT_STATE(_rs, \ + DEFAULT_RATELIMIT_INTERVAL, \ + DEFAULT_RATELIMIT_BURST); \ + if (__ratelimit(&_rs)) \ + mlog(mask, fmt, ##__VA_ARGS__); \ +} while (0) + #define mlog_errno(st) ({ \ int _st = (st); \ if (_st != -ERESTARTSYS && _st != -EINTR && \ _ Patches currently in -mm which might be from wen.gang.wang(a)oracle.com are

5 years, 11 months

1
0
0 0

[merged] mm-dont-reclaim-inodes-with-many-attached-pages.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: don't reclaim inodes with many attached pages has been removed from the -mm tree. Its filename was mm-dont-reclaim-inodes-with-many-attached-pages.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Roman Gushchin <guro(a)fb.com> Subject: mm: don't reclaim inodes with many attached pages Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs with a relatively small number of objects") leads to a regression on his setup: periodically the majority of the pagecache is evicted without an obvious reason, while before the change the amount of free memory was balancing around the watermark. The reason behind is that the mentioned above change created some minimal background pressure on the inode cache. The problem is that if an inode is considered to be reclaimed, all belonging pagecache page are stripped, no matter how many of them are there. So, if a huge multi-gigabyte file is cached in the memory, and the goal is to reclaim only few slab objects (unused inodes), we still can eventually evict all gigabytes of the pagecache at once. The workload described by Spock has few large non-mapped files in the pagecache, so it's especially noticeable. To solve the problem let's postpone the reclaim of inodes, which have more than 1 attached page. Let's wait until the pagecache pages will be evicted naturally by scanning the corresponding LRU lists, and only then reclaim the inode structure. Link: http://lkml.kernel.org/r/20181023164302.20436-1-guro@fb.com Signed-off-by: Roman Gushchin <guro(a)fb.com> Reported-by: Spock <dairinin(a)gmail.com> Tested-by: Spock <dairinin(a)gmail.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Rik van Riel <riel(a)surriel.com> Cc: Randy Dunlap <rdunlap(a)infradead.org> Cc: <stable(a)vger.kernel.org> [4.19.x] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/inode.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/fs/inode.c~mm-dont-reclaim-inodes-with-many-attached-pages +++ a/fs/inode.c @@ -730,8 +730,11 @@ static enum lru_status inode_lru_isolate return LRU_REMOVED; } - /* recently referenced inodes get one more pass */ - if (inode->i_state & I_REFERENCED) { + /* + * Recently referenced inodes and inodes with many attached pages + * get one more pass. + */ + if (inode->i_state & I_REFERENCED || inode->i_data.nrpages > 1) { inode->i_state &= ~I_REFERENCED; spin_unlock(&inode->i_lock); return LRU_ROTATE; _ Patches currently in -mm which might be from guro(a)fb.com are

5 years, 11 months

1
0
0 0

[merged] mm-use-kvzalloc-for-swap_info_struct-allocation.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/swapfile.c: use kvzalloc for swap_info_struct allocation has been removed from the -mm tree. Its filename was mm-use-kvzalloc-for-swap_info_struct-allocation.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Vasily Averin <vvs(a)virtuozzo.com> Subject: mm/swapfile.c: use kvzalloc for swap_info_struct allocation a2468cc9bfdf ("swap: choose swap device according to numa node") changed 'avail_lists' field of 'struct swap_info_struct' to an array. In popular linux distros it increased size of swap_info_struct up to 40 Kbytes and now swap_info_struct allocation requires order-4 page. Switch to kvzmalloc allows to avoid unexpected allocation failures. Link: http://lkml.kernel.org/r/fc23172d-3c75-21e2-d551-8b1808cbe593@virtuozzo.com Fixes: a2468cc9bfdf ("swap: choose swap device according to numa node") Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> Acked-by: Aaron Lu <aaron.lu(a)intel.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Huang Ying <ying.huang(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/swapfile.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/mm/swapfile.c~mm-use-kvzalloc-for-swap_info_struct-allocation +++ a/mm/swapfile.c @@ -2813,7 +2813,7 @@ static struct swap_info_struct *alloc_sw unsigned int type; int i; - p = kzalloc(sizeof(*p), GFP_KERNEL); + p = kvzalloc(sizeof(*p), GFP_KERNEL); if (!p) return ERR_PTR(-ENOMEM); @@ -2824,7 +2824,7 @@ static struct swap_info_struct *alloc_sw } if (type >= MAX_SWAPFILES) { spin_unlock(&swap_lock); - kfree(p); + kvfree(p); return ERR_PTR(-EPERM); } if (type >= nr_swapfiles) { @@ -2838,7 +2838,7 @@ static struct swap_info_struct *alloc_sw smp_wmb(); nr_swapfiles++; } else { - kfree(p); + kvfree(p); p = swap_info[type]; /* * Do not memset this entry: a racing procfs swap_next() _ Patches currently in -mm which might be from vvs(a)virtuozzo.com are

5 years, 11 months

1
0
0 0

[merged] hugetlbfs-fix-kernel-bug-at-fs-hugetlbfs-inodec-444.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: hugetlbfs: fix kernel BUG at fs/hugetlbfs/inode.c:444! has been removed from the -mm tree. Its filename was hugetlbfs-fix-kernel-bug-at-fs-hugetlbfs-inodec-444.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: hugetlbfs: fix kernel BUG at fs/hugetlbfs/inode.c:444! This bug has been experienced several times by Oracle DB team. The BUG is in remove_inode_hugepages() as follows: /* * If page is mapped, it was faulted in after being * unmapped in caller. Unmap (again) now after taking * the fault mutex. The mutex will prevent faults * until we finish removing the page. * * This race can only happen in the hole punch case. * Getting here in a truncate operation is a bug. */ if (unlikely(page_mapped(page))) { BUG_ON(truncate_op); In this case, the elevated map count is not the result of a race. Rather it was incorrectly incremented as the result of a bug in the huge pmd sharing code. Consider the following: - Process A maps a hugetlbfs file of sufficient size and alignment (PUD_SIZE) that a pmd page could be shared. - Process B maps the same hugetlbfs file with the same size and alignment such that a pmd page is shared. - Process B then calls mprotect() to change protections for the mapping with the shared pmd. As a result, the pmd is 'unshared'. - Process B then calls mprotect() again to chage protections for the mapping back to their original value. pmd remains unshared. - Process B then forks and process C is created. During the fork process, we do dup_mm -> dup_mmap -> copy_page_range to copy page tables. Copying page tables for hugetlb mappings is done in the routine copy_hugetlb_page_range. In copy_hugetlb_page_range(), the destination pte is obtained by: dst_pte = huge_pte_alloc(dst, addr, sz); If pmd sharing is possible, the returned pointer will be to a pte in an existing page table. In the situation above, process C could share with either process A or process B. Since process A is first in the list, the returned pte is a pointer to a pte in process A's page table. However, the following check for pmd sharing is in copy_hugetlb_page_range. /* If the pagetables are shared don't copy or take references */ if (dst_pte == src_pte) continue; Since process C is sharing with process A instead of process B, the above test fails. The code in copy_hugetlb_page_range which follows assumes dst_pte points to a huge_pte_none pte. It copies the pte entry from src_pte to dst_pte and increments this map count of the associated page. This is how we end up with an elevated map count. To solve, check the dst_pte entry for huge_pte_none. If !none, this implies PMD sharing so do not copy. Link: http://lkml.kernel.org/r/20181105212315.14125-1-mike.kravetz@oracle.com Fixes: c5c99429fa57 ("fix hugepages leak due to pagetable page sharing") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reviewed-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Prakash Sangappa <prakash.sangappa(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) --- a/mm/hugetlb.c~hugetlbfs-fix-kernel-bug-at-fs-hugetlbfs-inodec-444 +++ a/mm/hugetlb.c @@ -3233,7 +3233,7 @@ static int is_hugetlb_entry_hwpoisoned(p int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src, struct vm_area_struct *vma) { - pte_t *src_pte, *dst_pte, entry; + pte_t *src_pte, *dst_pte, entry, dst_entry; struct page *ptepage; unsigned long addr; int cow; @@ -3261,15 +3261,30 @@ int copy_hugetlb_page_range(struct mm_st break; } - /* If the pagetables are shared don't copy or take references */ - if (dst_pte == src_pte) + /* + * If the pagetables are shared don't copy or take references. + * dst_pte == src_pte is the common case of src/dest sharing. + * + * However, src could have 'unshared' and dst shares with + * another vma. If dst_pte !none, this implies sharing. + * Check here before taking page table lock, and once again + * after taking the lock below. + */ + dst_entry = huge_ptep_get(dst_pte); + if ((dst_pte == src_pte) || !huge_pte_none(dst_entry)) continue; dst_ptl = huge_pte_lock(h, dst, dst_pte); src_ptl = huge_pte_lockptr(h, src, src_pte); spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING); entry = huge_ptep_get(src_pte); - if (huge_pte_none(entry)) { /* skip none entry */ + dst_entry = huge_ptep_get(dst_pte); + if (huge_pte_none(entry) || !huge_pte_none(dst_entry)) { + /* + * Skip if src entry none. Also, skip in the + * unlikely case dst entry !none as this implies + * sharing with another vma. + */ ; } else if (unlikely(is_hugetlb_entry_migration(entry) || is_hugetlb_entry_hwpoisoned(entry))) { _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are

5 years, 11 months

1
0
0 0

PASS: Test report for kernel 4.19.4-rc1.skt+ (linux-stable-rc)

by CKI

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 2b8db8734888 Linux 4.19.4-rc1 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Hardware test: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( I ) Continuous `-',-.`-' Kernel ( K ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: arm64: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/aarch64/2b8db8734888b00156c6afb235… powerpc: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/ppc64le/2b8db8734888b00156c6afb235… powerpc: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/ppc64/2b8db8734888b00156c6afb235ed… x86_64: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/x86_64/2b8db8734888b00156c6afb235e…

5 years, 11 months

1
0
0 0

International credit settlement

by :COMPENSATION AGENTt

International credit settlement Office of the director of operations World Bank united state of America. Attention : This Is To Officially Inform You That We Have Verified Your Contact Inheritance File Presently On My Desk, And I Found Out That You Have Not Received Your Payment Due To Your Lack Of Co- Operation And Not Fulfilling The Obligations Giving To You In Respect To Your Contract /Inheritance Payment. Secondly, You Are Hereby Advice To Stop Dealing With Some Non- Officials In The Bank As This Is An Illegal Act And Will Have To Stop If You So Wish To Receive Your Payment Immediately. After The Board Meeting Held At Our Headquarters, We Have Resolved In Finding A Solution To Your Problem, And As You May Know, We Have Arranged Your Payment Through Our Swift Card Payment Center In Europe, America And Asia Pacific, Which Is Then Instruction Given By Our President. This Card Center Will Send You An ATM Card Which You Will Use To Withdraw Your Money In Any Part Of The World, But The Maximum Is ($15,000.00) Fifteen Thousand Us Dollars Per Transaction. So, If You Like To Receive Your Fund This Way, $15,000 Usd For You To Withdraw For A Day And Each Transaction Is $5,000usd Minimum Which You Have To Withdraw $15,000 Usd For One Working Day. Also Be Informed That The Total Amount In The Swift ATM Card Is $14.6 Million Usd. Contact:COMPENSATION AGENT Email:DavegibsonEsq@gmail.comcom (1) Your Full Name: (2) Your Address Where You Want the Payment Centre to Send Your ATM Card.: (3) Phone and Fax Number: (4) Age and Occupation: (5) Your Nearest International Air Port in Your City Of Residence: We Shall Be Expecting To Receive Your Information, You Have To Stop Any Further Communication With Anybody Or Office On This Regards, Do Not Hesitate To Contact Me For More Details And Direction, And Please Do Update Me With Any New Development. Thanks for Your Co-Operation.

5 years, 11 months

1
0
0 0

stable-rc/linux-3.18.y boot: 62 boots: 5 failed, 56 passed with 1 untried/unknown (v3.18.125-88-ge2a8617f7c3c)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 62 boots: 5 failed, 56 passed with 1 untried/unknown (v3.18.125-88-ge2a8617f7c3c) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.125-8… Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.125-88-ge2a8617f7c3c Git Commit: e2a8617f7c3c3a178aab5341fe2e6002dfa9efb9 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 25 unique boards, 12 SoC families, 14 builds out of 185 Boot Failures Detected: arm: exynos_defconfig exynos4412-odroidx2: 1 failed lab x86: x86_64_defconfig qemu: 3 failed labs x86-atom330: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2018