From patchwork Wed Oct 10 14:56:32 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Garry X-Patchwork-Id: 148563 Delivered-To: patch@linaro.org Received: by 2002:a2e:8595:0:0:0:0:0 with SMTP id b21-v6csp959070lji; Wed, 10 Oct 2018 07:54:37 -0700 (PDT) X-Google-Smtp-Source: ACcGV63JoHBMedbA7zvScqY6xqBU3kEiwl03taSQGJaq+4NKYb2sgXp7wWw/5jZV6/PTMA9gB5RK X-Received: by 2002:a63:e918:: with SMTP id i24-v6mr29899342pgh.64.1539183277011; Wed, 10 Oct 2018 07:54:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539183277; cv=none; d=google.com; s=arc-20160816; b=IlQoPdj4MyZy0VxCgG46NWwh7bW23WQDkzmJQrnuLKCdgi+4B2vmym6drfZolQd1s6 5ltzoD9kp22+ycoV8wbjk+vYHSHM69sfjBd3jf207MpmQhpUtPuVRRkBL3il5deWE/GP BZ2Hd2U/m1CADQdueuNMl+gMP+XkaGacX3fWgEtNLZkk3QkIRX7uRFsiVPJO5fzQEvcS a1KLm6BqKdtFEeL4xSMXydPpStP5ueJB8c0zYVLNeqKxWbywsyd3vkFMp9zukaSoxk/h KIUHZtxiCAFeWqgRsRsHtgaWxWUG89QoWOmbK2MTgztxy8yX4pm/8tn5ALvAkbo0gS9k Qy0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=itNEe9CkjyvYg1V1hIFptOJhBjm3kfKFkBIu7b6CuHw=; b=C9V3RuyuhvIb6lbSgCWtgLSlclNp0krjDR1QvH3FjoE3Z5fqRKnr95+VAij9IbouTa f+VoZf81A4hPibYfWpBT5cWwZyE8hza7tpEEa5UCM+EkMqCVuicBNzrQXTh8PTZX4wYC FMEpliHJZhvUN9nsfI3Ih4oc/HpuRV96VcXHljf7YPuN570Qc/E688EOQmEqj/NQBtrM SzrbRZZxKdHDp355imOOlcpx9GxZsazjh3/wVkW3mdAesJ7ur/UMUXmduM+851up41GA sChYwKEMw06MM3v5c/iEarJUz2BGiPdV1N2XDPgaV0D3Lan9ueEp26kifRJEi2nztUE8 UmSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 64-v6si26488264pft.177.2018.10.10.07.54.36; Wed, 10 Oct 2018 07:54:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726827AbeJJWRH (ORCPT + 32 others); Wed, 10 Oct 2018 18:17:07 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:58664 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726515AbeJJWRH (ORCPT ); Wed, 10 Oct 2018 18:17:07 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 601BAD95DA183; Wed, 10 Oct 2018 22:54:29 +0800 (CST) Received: from localhost.localdomain (10.67.212.75) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.399.0; Wed, 10 Oct 2018 22:54:23 +0800 From: John Garry To: CC: , , , , John Garry Subject: [PATCH] docs/completion.txt: Fix a couple of punctuation nits Date: Wed, 10 Oct 2018 22:56:32 +0800 Message-ID: <1539183392-239389-1-git-send-email-john.garry@huawei.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch fixes a couple of punctuation nits which can make the document more correct and readable. Also missing "()" are added to some function references for consistency. Signed-off-by: John Garry -- 1.9.1 Acked-by: Randy Dunlap diff --git a/Documentation/scheduler/completion.txt b/Documentation/scheduler/completion.txt index 656cf80..108bd0f 100644 --- a/Documentation/scheduler/completion.txt +++ b/Documentation/scheduler/completion.txt @@ -116,7 +116,7 @@ A typical usage scenario is: This is not implying any temporal order on wait_for_completion() and the call to complete() - if the call to complete() happened before the call to wait_for_completion() then the waiting side simply will continue -immediately as all dependencies are satisfied if not it will block until +immediately as all dependencies are satisfied; if not, it will block until completion is signaled by complete(). Note that wait_for_completion() is calling spin_lock_irq()/spin_unlock_irq(), @@ -131,7 +131,7 @@ wait_for_completion(): The default behavior is to wait without a timeout and to mark the task as uninterruptible. wait_for_completion() and its variants are only safe in process context (as they can sleep) but not in atomic context, -interrupt context, with disabled irqs. or preemption is disabled - see also +interrupt context, with disabled irqs, or preemption is disabled - see also try_wait_for_completion() below for handling completion in atomic/interrupt context. @@ -224,7 +224,7 @@ queue spinlock. Any such concurrent calls to complete() or complete_all() probably are a design bug. Signaling completion from hard-irq context is fine as it will appropriately -lock with spin_lock_irqsave/spin_unlock_irqrestore and it will never sleep. +lock with spin_lock_irqsave()/spin_unlock_irqrestore() and it will never sleep. try_wait_for_completion()/completion_done():