From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by sourceware.org (Postfix) with ESMTPS id 5CA8E385841C for ; Wed, 1 Mar 2023 18:01:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5CA8E385841C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orpolo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orpolo.org Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4PRhqh0w4Dz9sW9; Wed, 1 Mar 2023 19:01:04 +0100 (CET) Message-ID: <44d91128-f2e4-8aa7-1801-bdecef7797cb@orpolo.org> Date: Wed, 1 Mar 2023 19:01:02 +0100 MIME-Version: 1.0 From: Luca Subject: Re: [PATCH 1/2] hurd: Remove the ecx kludge To: Sergey Bugaev , Samuel Thibault , bug-hurd@gnu.org, libc-alpha@sourceware.org References: <20230301092421.x6derf2if5tc3u5u@begin> <20230301162355.426887-1-bugaevc@gmail.com> Content-Language: en-US, it In-Reply-To: <20230301162355.426887-1-bugaevc@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, Il 01/03/23 17:23, Sergey Bugaev ha scritto: > "We don't need it any more" > > The INTR_MSG_TRAP macro in intr-msg.h used to play little trick with > the stack pointer: it would temporarily save the "real" stack pointer > into ecx, while setting esp to point to just before the message buffer, > and then invoke the mach_msg trap. This way, INTR_MSG_TRAP reused the > on-stack arguments laid out for the containing call of > _hurd_intr_rpc_mach_msg (), passing them to the mach_msg trap directly. > > This, however, required special support in hurdsig.c and trampoline.c, > since they now had to recognize when a thread is inside the piece of > code where esp doesn't point to the real tip of the stack, and handle > this situation specially. > > Commit 1d20f33ff4fb634310f27493b7b87d0b20f4a0b0 has removed the actual > temporary change of esp by actually re-pushing mach_msg arguments onto > the stack, and popping them back at end. It did not, however, deal with > the rest of "the ecx kludge" code in other files, resulting in potential > crashes if a signal arrives in the middle of pushing arguments onto the > stack. > > Fix that by removing "the ecx kludge". Instead, when we want a thread > to skip the RPC, but cannot make just make it jump to after the trap > since it's not done adjusting the stack yet, set the SYSRETURN register > to MACH_SEND_INTERRUPTED (as we do anyway), and rely on the thread > itself for detecting this case and skipping the RPC. I still have to fully understand the existing code, so this might be something completely wrong... but if interrupting an rpc is a complex thing to do reliably in user space, why not add some kernel support? Also, how do you test this code? For example, we could add a thread_interrupt_rpc() where the kernel could just check the state of the suspended thread: * if the thread has a continuation set it means it still has to finish the send/recv operation, so we replace the continuation, discard the previous syscall state, and we just return an RPC_INTERRUPTED_BY_USER code or MACH_SEND/RCV_INTERRUPTED. * if the thread finished the syscall, but it was de-scheduled before returning to userspace (by AST) it will just return normally, as the syscall was executed completely. There could also be a new option to mach_msg(), so we can have uninterruptible mach_msg() if needed, or reuse MACH_SEND/RCV_INTERRUPT. Does it make sense? Also, if I understand correctly, in case the thread finished the syscall and successfully received a message, but didn't return to userspace yet, isn't there the risk of losing the message, with the current approach? Luca