Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp5172896pxu; Tue, 22 Dec 2020 10:01:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJzBirdH0zud7KInmT34Q0kLB1woKryfAKpOczUBh54roNUsWezGiUIHYaxSSOcS8qDBbMdp X-Received: by 2002:a17:906:9257:: with SMTP id c23mr11219642ejx.82.1608660117668; Tue, 22 Dec 2020 10:01:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608660117; cv=none; d=google.com; s=arc-20160816; b=OsJFpuAz+NFdVU2sRiV1hbYONmo/8O88bF3IQbq564k68LX3JTgtWebG1smshk2Hb4 tGGH5c8Nt7sLYdhgYFgUIQpXwfRM5d6L4Vee8GlKS+nNFZdk0lE21QFSFh8+GG4ibUBa pEmNUt8AxynseyEjotRRqYTribEkHB5EFfYUZZHSvsuU+9SFhMIuzA2yxXg7KWdiDaes EYpy0MLI2GyBzA2GFK6jdrNyCrBxx/0yLa1m86W5pQ9GkY+R4GRun+3pcdhLSU7FBP4B 5zN2VzEAx43dEo+JRdYmfoH6uLFRwX4h2t6HDfrHjz8ArCwHTC860ozYbBzLvvR8Nbb9 ZKrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:user-agent:date:message-id:subject:from:cc:to :authorized-sender; bh=jaNJ/qJ+lIq4MArbbi5uy6Zg1Z/1LabLpEmvOpmemo0=; b=WpyYgIyj9men2ZKb0JaD+fdmRN9ILNbNREEOXUY2xSz8cDY3+B7eNBhq1H7bRL6iGX HCwUyVoIR8oyBE3uHw/eOurroVqMPb0iN8BC6NY9OhSn83E6bQXn2VvMWintJw8ys0kx QGjppC2ybTkjQubJdmtd8SOfXlqXHh9iLzFwxYTtauyj2lMeKuJPLpZ55xpdIpFaos7J MfOSL5EM6jFAIP6Tv1D1pwQ+gV3aFhW4n4UpZdUFpPRTtFbM62f6ztcm74/ZPwvSU8ao bOYkyZSAVW4QcEr8ea0W7rnJCj5QteUX6TpCT2OALscYojPV+mvK89VsqfkT0yQa2a/f N5dg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a28si12591197edb.462.2020.12.22.10.01.33; Tue, 22 Dec 2020 10:01:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728064AbgLVR7t (ORCPT + 99 others); Tue, 22 Dec 2020 12:59:49 -0500 Received: from bin-mail-out-05.binero.net ([195.74.38.228]:14203 "EHLO bin-mail-out-05.binero.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727094AbgLVR7t (ORCPT ); Tue, 22 Dec 2020 12:59:49 -0500 X-Halon-ID: 5e35e258-447f-11eb-b73f-0050569116f7 Authorized-sender: andreas@gaisler.com Received: from andreas.got.gaisler.com (h-98-128-223-123.na.cust.bahnhof.se [98.128.223.123]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPA id 5e35e258-447f-11eb-b73f-0050569116f7; Tue, 22 Dec 2020 18:59:04 +0100 (CET) To: Thomas Gleixner , sparclinux , linux-mm@kvack.org Cc: "David S. Miller" , Arnd Bergmann , "linux-kernel@vger.kernel.org" , Sam Ravnborg From: Andreas Larsson Subject: sparc32: Init process fails to load with generic kmap atomic Message-ID: Date: Tue, 22 Dec 2020 18:58:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Unfortunately I did not see this problem before I encountered it in master. Commit 3293efa9780712ad8504689e0c296d2bd33827d5 sparc/mm/highmem: Switch to generic kmap atomic No reason having the same code in every architecture Signed-off-by: Thomas Gleixner Cc: "David S. Miller" Cc: Arnd Bergmann Link: https://lore.kernel.org/r/20201103095858.197568209@linutronix.de prevents the init process to be started for me on a sparc32 LEON. On the commit before this it works. Details below from that commit but I get the same behavior on current master. From as far as I have gotten into hunting down the problem, I get a failure from load_elf_binary here: /* First of all, some simple consistency checks */ if (memcmp(elf_ex->e_ident, ELFMAG, SELFMAG) != 0) goto out; at least seemingly due to the kaddr from copy_page_to_iter in lib/iov_iter.c if (i->type & (ITER_BVEC|ITER_KVEC)) { void *kaddr = kmap_atomic(page); size_t wanted = copy_to_iter(kaddr + offset, bytes, i); where kaddr points to memory with all zeroes (from an earlier bzero) in this context: #0 _copy_to_iter (addr=0xfcffe000, bytes=0x100, i=0xf201fd78) at lib/iov_iter.c:635 #1 copy_to_iter (i=0xf201fd78, bytes=0x1ce, addr=0xfcffe000) at include/linux/uio.h:137 #2 copy_page_to_iter (page=0xf137ede0, offset=0x0, bytes=0x1ce, i=0xf201fd78) at lib/iov_iter.c:920 #3 shmem_file_read_iter (iocb=0xf201fd90, to=0xf201fd78) at mm/shmem.c:2661 #4 __kernel_read (file=0xf2103900, buf=0xf241365c, count=0x100, pos=0xf201fe80) at fs/read_write.c:454 #5 kernel_read (file=0xf2103900, buf=0xf241365c, count=0x100, pos=0xf201fe80) at fs/read_write.c:472 #6 prepare_binprm (bprm=0xf2413600) at fs/exec.c:1633 #7 search_binary_handler (bprm=0xf2413600) at fs/exec.c:1687 #8 exec_binprm (bprm=0xf2413600) at fs/exec.c:1744 #9 bprm_execve (bprm=0xf2413600, fd=, filename=, flags=) at fs/exec.c:1820 #10 kernel_execve (kernel_filename=, argv=0xf050d4f0 , envp=0xf050d468 ) at fs/exec.c:1969 #11 kernel_init (unused=0x0) at init/main.c:1427 I will have to continue to dig deeper into this in January. If anyone has any ideas how this could stem from this kmap patch, I am all ears. -- Andreas Larsson Software Engineer Cobham Gaisler