From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 169F717C9E8 for ; Fri, 20 Dec 2024 07:22:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734679356; cv=none; b=OtR6tQWTty4UENdfufvaZbBFKA6rMU5zIJBIIqkHwUbpvqnbP9bngAYfZ6sEQpSGSRaISwE3rwbiD8XUIYkZa5QNz+m79LKcMH9YKhXO8LZrTDwBR5Ve6MMRJ05O+9fXtXjhWQrgwhs5w+En9/VdZrfswFHAxnaWY0aZmjUalBM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734679356; c=relaxed/simple; bh=mD0SSobIGbBT5eejdQTqxB+QHJJCwWIlX7PTGwwLltQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Xdux0boJPCXoyIApal81A+Z9xFj/nsVKG9xXy35UlwJMYFmwGbvSPIChTBV3Afkjfm1nntjO2MDB1zfZQkVjm0fbqvR9idvoREyyw5PfN5N00XSczhX5W+pMJ+bB1ey+KYcNyFOczONji+JN244xvu5bgCypRvV5ZBTZVTkjvbI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=B9L022jn; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="B9L022jn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734679352; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VV1GAbU6vs/Ml1xhCadOL44dM9zTf3oC8kpgBVJ9ouw=; b=B9L022jn3F+/LDYrFzMgTz0i3L0ownW++0pFwtIbrlIz7LMepHgurI3xju7c/qoLuDH5ni LBBIZu6flgHHc1p1FkqLM103V2Ze0IiUB+VTTYWqq4ckzt3Ir7Bs8wbOfQguscU8Ro7jxD BmZLkwy5kCeGwxvm6yqUTdhN9aBMwZI= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-589-r-LCiKK2MmeyGdwoo16F7g-1; Fri, 20 Dec 2024 02:22:25 -0500 X-MC-Unique: r-LCiKK2MmeyGdwoo16F7g-1 X-Mimecast-MFC-AGG-ID: r-LCiKK2MmeyGdwoo16F7g Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 0BD7B195608C; Fri, 20 Dec 2024 07:22:24 +0000 (UTC) Received: from localhost (unknown [10.66.37.175]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5A1B719560A2; Fri, 20 Dec 2024 07:22:21 +0000 (UTC) Date: Fri, 20 Dec 2024 15:22:17 +0800 From: Baoquan He To: "Eric W. Biederman" Cc: David Woodhouse , "Rafael J. Wysocki" , Thomas Gleixner , Ming Lei , LKML , Linux PM , Kexec Mailing List Subject: Re: Does anyone actually use KEXEC_JUMP? Message-ID: References: <4968818.GXAFRqVoOG@rjwysocki.net> <87h673zkhr.fsf_-_@email.froward.int.ebiederm.org> <87bjxbzdyq.fsf@email.froward.int.ebiederm.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bjxbzdyq.fsf@email.froward.int.ebiederm.org> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 On 12/16/24 at 12:21pm, Eric W. Biederman wrote: > David Woodhouse writes: > > > It isn't broken. I know of it being used a few million times a week. > > > > There are corner cases which have never worked right, like the callee > > putting a different return address for its next invocation, on the > > stack *above* the address it 'ret's to. Which since the first kjump > > patch has been the first word of the page *after* the swap page (and > > is now fixed in my tree). But fundamentally it *does* work. > > > > I only started messing with it because I was working on > > relocate_kernel() and needed to write a test case for it; the fact > > that I know of it being used in production is actually just a > > coincidence. > > Cool. I had the sense that the original developer never got around > to using it, so I figured I should check. > > Mind if I ask what you know of it being used for? I am also very curious about the use case and asked David in other thread, while David didn't tell. Not sure if it's one company's confidential information. We may want to know what it's used for to evaluate if it's a generally useful use case, or an unintentional testing. > > I had imagined it might be a way to call firmware code preventing the > need to code of a specific interface for each type of firmware. > > Eric > >