From patchwork Wed Jun 28 19:56:17 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 114037 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp9181717vqr; Wed, 28 Jun 2023 13:11:22 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7Cw7sh1CJ+xlxG1o7Pr3ZTwcr6jTWuqNIDUwxgKnyyOmkCy0RNr4M/iP1ENCtK94vaG2yo X-Received: by 2002:a05:6a20:432a:b0:126:c759:27f8 with SMTP id h42-20020a056a20432a00b00126c75927f8mr14260892pzk.2.1687983082415; Wed, 28 Jun 2023 13:11:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687983082; cv=none; d=google.com; s=arc-20160816; b=H9PG1LcmWds9FUlchk3fWGIy38pdK34GPH2CpsnxEuPVVlOa1l16eIwmWMyAbvJc6c mhkbsoC0+BMPJJV00uPDsdVGLJp4OWpMPHdwQWgbC4bZktp6lxT1FsSmnWY3O6s3tlC2 dGhEQnceefN1ciyLtKaOgDTMN+9o3ACT8iHnod6yBlPrxKjBNNDwkgkc8il0bruEvbIs iQI/8khgO1Y2wDJaHcPBOtqu0QTBe5TEi4Hya3KIpMhvCxBjo2bc6YHZRU6QzUuW1JMa Wk3Sb2C2ptaqAEfYR8lMT8FcQVzSDvz7Y9bMg6Bs8lvzUN4xL5W6EyH117MMzcuZPsz6 e+iA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=SLKKj3K4u0AlIAtmQW7z5se9epOJGry5f3WiL2g4NwY=; fh=Rhse0CdafAEjvYTlwHylktrkVJhO/YUgX3jXUbGK7m0=; b=m746xKk0J/acmyB4XaeQ84RAJV9eUNsJP0ZFws3LGJvuoFBlRE2ZWVmKYA2B9Lc91f SLN5GNUIo94r66ThjuSPnunJpseUtV1JdPxmn1diW7qy3JPyY2qstWdB/seHn3Sc/KwU 3Zv9SfikGB7KmZJ2jBr1heCqYT3qO03fNO35/mkBUrFFfwnc/2Q/3JrAQYN7CTXvwoFh 9w21bUby5xuPJrSPwpj+IytHL1WJWpfeBy7pCYZ+3cg2FFrcSNQw/hOYcYgw7ZQEHdIn evVbDBBIB45sNQajmTOwh573TfTLYTqRjCpkPbvnt9mCRLRSNotpGM7w7T6iYK3M0rVx Q6Kg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=bX9n4EZZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w37-20020a631625000000b005539899e4cdsi9949300pgl.813.2023.06.28.13.11.09; Wed, 28 Jun 2023 13:11:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=bX9n4EZZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231532AbjF1T6V (ORCPT + 99 others); Wed, 28 Jun 2023 15:58:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231361AbjF1T6T (ORCPT ); Wed, 28 Jun 2023 15:58:19 -0400 Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 257941FE7 for ; Wed, 28 Jun 2023 12:58:18 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-53fbf2c42bfso56025a12.3 for ; Wed, 28 Jun 2023 12:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1687982297; x=1690574297; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=SLKKj3K4u0AlIAtmQW7z5se9epOJGry5f3WiL2g4NwY=; b=bX9n4EZZyTbXN54Rp0GUhOYll5IXE//1a0nNjN2h20oHk4WN/oIlsZWQFuTtDjNB3s a0ls74kLCHwip1lHi8qogxSWcaGBS6fcnDHDR26NY29EEYazFE7nYZEwDlzaY4KmCu1z iN9/b9wlgfLjIXCZRzzSwOVfWJtLNKQEP06VI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687982297; x=1690574297; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SLKKj3K4u0AlIAtmQW7z5se9epOJGry5f3WiL2g4NwY=; b=UMMhze2fWCQKqgra1/4UQ01ZNAVbLYMjDlGks+ZkTslsGOaKuDBwZ2awHLyPLcv0Ey Bmc67P0OmNTZLmYisnn+Peq07N2d+6QzYDIy0KjQ5qrsyEquQaLoubBTjGHuuqITIQUi 8Bk40V4oD3Xdac+4Ajcrk1XWedLt3EU0SWuhcNh2OejhfBTCMffbLn5aJ08r9BSnuSpa aXRdu8UOBa/V8j4NdXcukKypfBA7tx8XFSVgGGdUm0Ee3NxtIfO/71zkeoGMitYh8SRH QZRYuMjM7uEX0EkfpfB3GTKq4ANY5Avvv18HxSUrwm0CF2rJSqSGoJcXW1ZJSFl+1RSW 8oAQ== X-Gm-Message-State: AC+VfDy2IKZZFu3UyFIFU0CKgR2Lzc++ogD3QrmwX6JczJQ2N/0gW02s LcVOIwEglC65v/z76+epZD0A9g== X-Received: by 2002:a17:90a:930f:b0:262:ebb9:dd59 with SMTP id p15-20020a17090a930f00b00262ebb9dd59mr9131691pjo.20.1687982297575; Wed, 28 Jun 2023 12:58:17 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:1228:a4c5:d742:666b]) by smtp.gmail.com with ESMTPSA id nw13-20020a17090b254d00b00262ff206931sm5040108pjb.42.2023.06.28.12.58.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jun 2023 12:58:16 -0700 (PDT) From: Douglas Anderson To: Daniel Thompson Cc: Douglas Anderson , Aaron Tomlin , Jason Wessel , John Ogness , Petr Mladek , kgdb-bugreport@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: [PATCH] kdb: Handle LF in the command parser Date: Wed, 28 Jun 2023 12:56:17 -0700 Message-ID: <20230628125612.1.I5cc6c3d916195f5bcfdf5b75d823f2037707f5dc@changeid> X-Mailer: git-send-email 2.41.0.162.gfafddb0af9-goog MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769978548197750731?= X-GMAIL-MSGID: =?utf-8?q?1769978548197750731?= The main kdb command parser only handles CR (ASCII 13 AKA '\r') today, but not LF (ASCII 10 AKA '\n'). That means that the kdb command parser can handle terminals that send just CR or that send CR+LF but can't handle terminals that send just LF. The fact that kdb didn't handle LF in the command parser tripped up a tool I tried to use with it. Specifically, I was trying to send a command to my device to resume it from kdb using a ChromeOS tool like: dut-control cpu_uart_cmd:"g" That tool only terminates lines with LF, not CR+LF. Arguably the ChromeOS tool should be fixed. After all, officially kdb seems to be designed such that CR+LF is the official line ending transmitted over the wire and that internally a line ending is just '\n' (LF). Some evidence: * uart_poll_put_char(), which is used by kdb, notices a '\n' and converts it to '\r\n'. * kdb functions specifically use '\r' to get a carriage return without a newline. You can see this in the pager where kdb will write a '\r' and then write over the pager prompt. However, all that being said there's no real harm in accepting LF as a command terminator in the kdb parser and doing so seems like it would improve compatibility. After this, I'd expect that things would work OK-ish with a remote terminal that used any of CR, CR+LF, or LF as a line ending. Someone using CR as a line ending might get some ugliness where kdb wasn't able to overwrite the last line, but basic commands would work. Someone using just LF as a line ending would probably also work OK. A few other notes: - It can be noted that "bash" running on an "agetty" handles LF as a line termination with no complaints. - Historically, kdb's "pager" actually handled either CR or LF fine. A very quick inspection would make one think that kdb's pager actually could have paged down two lines instead of one for anyone using CR+LF, but this is generally avoided because of kdb_input_flush(). - Conceivably one could argue that some of this special case logic belongs in uart_poll_get_char() since uart_poll_put_char() handles the '\n' => '\r\n' conversion. I would argue that perhaps we should eventually do the opposite and move the '\n' => '\r\n' out of uart_poll_put_char(). Having that conversion at such a low level could interfere if we ever want to transfer binary data. In addition, if we truly made uart_poll_get_char() the inverse of uart_poll_put_char() it would convert back to '\n' and (ironically) kdb's parser currently only looks for '\r' to find the end of a command. Signed-off-by: Douglas Anderson --- kernel/debug/kdb/kdb_io.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c index 5c7e9ba7cd6b..813cb6cf72d6 100644 --- a/kernel/debug/kdb/kdb_io.c +++ b/kernel/debug/kdb/kdb_io.c @@ -131,6 +131,7 @@ char kdb_getchar(void) int escape_delay = 0; get_char_func *f, *f_prev = NULL; int key; + static bool last_char_was_cr; for (f = &kdb_poll_funcs[0]; ; ++f) { if (*f == NULL) { @@ -149,6 +150,18 @@ char kdb_getchar(void) continue; } + /* + * The caller expects that newlines are either CR or LF. However + * some terminals send _both_ CR and LF. Avoid having to handle + * this in the caller by stripping the LF if we saw a CR right + * before. + */ + if (last_char_was_cr && key == '\n') { + last_char_was_cr = false; + continue; + } + last_char_was_cr = (key == '\r'); + /* * When the first character is received (or we get a change * input source) we set ourselves up to handle an escape @@ -244,7 +257,8 @@ static char *kdb_read(char *buffer, size_t bufsize) *cp = tmp; } break; - case 13: /* enter */ + case 10: /* linefeed */ + case 13: /* carriage return */ *lastchar++ = '\n'; *lastchar++ = '\0'; if (!KDB_STATE(KGDB_TRANS)) {