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;
From:   Liam Howlett <liam.howlett@oracle.com>
To:     "Eric W. Biederman" <ebiederm@xmission.com>
CC:     Will Deacon <will@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Julien Grall <julien.grall@arm.com>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: Re: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
Thread-Topic: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn()
 sometime returns the wrong signals
Thread-Index: AQHXNgU7cqnWwo9uSUqkb8fv6D7LrKrAf6QAgABdihGAABDSgIABgYVxgAAb1ICACUmEkIABocSA
Date:   Fri, 30 Apr 2021 18:48:08 +0000
Message-ID: <20210430184757.mez7ujmyzm43g6z2@revolver>
References: <20210420165001.3790670-1-Liam.Howlett@Oracle.com>
 <20210420165001.3790670-2-Liam.Howlett@Oracle.com>
 <20210422124849.GA1521@willie-the-truck> <m1v98egoxf.fsf@fess.ebiederm.org>
 <20210422192349.ekpinkf3wxnmywe3@revolver> <m1y2d8dfx8.fsf@fess.ebiederm.org>
 <20210423200126.otleormmjh22joj3@revolver> <m1czud6krk.fsf@fess.ebiederm.org>
In-Reply-To: <m1czud6krk.fsf@fess.ebiederm.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <38C7F8000F14444EB388C40FB3D20C5F@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 16078c39-63c8-496d-8652-08d90c087f66
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2021 18:48:08.4783
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: x52Q+Ar8c17MQalN5odCr3Kr11XWWfOrVxqsTA7aU7qkMCl7jWeNQzazblYqj5e9SbC6NTMiFlhvIeLfNYCYSQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1001MB2416
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9970 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0
 mlxlogscore=999 bulkscore=0 phishscore=0 spamscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000
 definitions=main-2104300127
X-Proofpoint-GUID: Hck_2i5oYsjL3ukberMMCBWfua9EZBp_
X-Proofpoint-ORIG-GUID: Hck_2i5oYsjL3ukberMMCBWfua9EZBp_
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9970 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 lowpriorityscore=0
 mlxlogscore=999 malwarescore=0 phishscore=0 priorityscore=1501
 clxscore=1015 spamscore=0 bulkscore=0 suspectscore=0 adultscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2104060000 definitions=main-2104300127
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

This is way out of scope for what I'm doing.  I'm trying to fix a call
to the wrong mm API.  I was trying to clean up any obvious errors in
calling functions which were exposed by fixing that error.  If you want
this fixed differently, then please go ahead and tackle the problems you
see.

Thank you,
Liam


* Eric W. Biederman <ebiederm@xmission.com> [210429 13:52]:
>=20
> This entire discussion seems to come down to what are the expected
> semantics of arm64_notify_segfault.  The use of this helper in
> swp_handler and user_cache_main_handler is clearly for the purposes of
> instruction emulation.  With instruction emulation it is a bug if the
> emulated instruction behaves differently than a real instruction in
> the same circumstances.
>=20
> To properly fix the instruction emulation in arm64_notify_segfault it
> looks to me that the proper solution is to call __do_page_fault or
> handle_mm_fault the way do_page_fault does and them parse the VM_FAULT
> code for which signal to generate.
>=20
> I would probably rename arm64_notify_segfault to arm64_emulate_fault, or
> possibly arm64_notify_fault while fixing the emulation so that it
> can return different signals and so that people don't have to guess
> what the function is supposed to do.
>=20
> For the specific case of sigreturn and rt_sigreturn it looks sufficient
> to use the fixed arm64_notify_segfault.  As it appears the that the code
> is attempting to act like it is emulating an instruction that does not
> exist.
>=20
>=20
> There is an argument that sigreturn and rt_sigreturn do a poor enough
> job of acting like the fault was caused by an instruction, as well
> as failing for other reasons it might make more sense to just have
> sigreturn and rt_sigreturn call "force_sig(SIGSEGV);"  But that seems
> out of scope of what you are trying to fix right now so I would not
> worry about it.
>=20
> Eric=