Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp672793ybh; Sat, 3 Aug 2019 07:26:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqw0vfkg5qnJGk22xBb4S+HZ2RZbwbt3pdAHHstLeC2U6zC12sgqhIiH0mFgC3o604FJQlwp X-Received: by 2002:a65:50c5:: with SMTP id s5mr18707049pgp.368.1564842368662; Sat, 03 Aug 2019 07:26:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564842368; cv=none; d=google.com; s=arc-20160816; b=FNh5RBwzlnyOzFgY9kE42BtdSDirMU3ZOFt2R+0ZEqF42KgJMQSNVe3gpNgfLtzTD/ bVSyEN5rG8SyBbZp3Te0+stiOE2zgSx7zk5Qp7kSf+NjbWJpQo5Aso8srS51wQCGLBge la+8m0ywkW4ss881pbVQ1w6/RgrRTUIwqkBDOMOVAgeLOMg3np+JQm7PQLHTnrlydeHJ yI140gvHtz+203Im+NG3aKXKSwyYwynJa4CrVIuuJhvKjWXObRUnqTUoMZQv0rVEAkRF UJgBGH+fXVCC5B9/qol/MT6ynohHZl7jBUObNePafuB1cc63GjP5xV1pM8EhFqfDYhqy BPzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=txRNymCLa0F2sH7rm1U39uNCjUyxuuiLjvn3rhtof6o=; b=Xj758Z1tqM1oESQnjJPsgoycyKGHd0kj8WDRb8qWu2HNE2NOGE0kZftJ+XBoqFXGov 3pV+j7YB8HfFt1DqFgKGxaSEYxvJSKzY/kJzkiXcdQuSH/6CIVpkE5y3o8SICnoBkBLS VnUm16rqbRfefO0PklpyRfyBm4v4ooPrLupSW5zVuuzeFBxS9CwLsTD+PHoU6IQyFqmu GVxt/VrrbImdzq2rbEVaTSwtI9bWu+jCQFgSJHZAZseDhsyCrDe25wsc2PvN5BkXZqtj xNx+5haee4N8/awfWSetDRS45nb1V+YCy7ePF+4FlH5uzHzOqtnrDovQ4hpyMICDvG1c WS3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lO9QmjHP; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l21si19772832pgk.259.2019.08.03.07.25.54; Sat, 03 Aug 2019 07:26:08 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lO9QmjHP; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387464AbfHBPOs (ORCPT + 99 others); Fri, 2 Aug 2019 11:14:48 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:38351 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728719AbfHBPOr (ORCPT ); Fri, 2 Aug 2019 11:14:47 -0400 Received: by mail-ed1-f67.google.com with SMTP id r12so37901371edo.5; Fri, 02 Aug 2019 08:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=txRNymCLa0F2sH7rm1U39uNCjUyxuuiLjvn3rhtof6o=; b=lO9QmjHP6O41ZCS8dtxftVcEU1ZMBi8DcpvUMY0blH5Qwqs9An8SwEtYIu4kI6xBqO ROSjy4jrgZxUHgj+PoMsKXXOnCBPtY5s3OefBgajHeizJfCRzEQMpfJZsxWfs2ziBXQr i8FM3V169K4mBiBVZU798HtbOMxk+zE0F74fIx/mFQP3tKcsbIYJQNMVfDCKLixaXC73 nOlcLwXTCJweexIyOsfohKaVuLPfBukqQrOIEHK1aRxxDDXvRW34lsQSzs7tYjyBU7tI 35VsEtCMIxfCasrfUvsocJfMQjs6gT5qlNs4oH7gbeoS5iNqtHQ+9CscZuIBYXg+ZC0P 1jiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=txRNymCLa0F2sH7rm1U39uNCjUyxuuiLjvn3rhtof6o=; b=mUCERXEelUt/qhezWeh7jdYMOZdTzoMRelgkcaMdPwJ0EmaUKo7jy+IdYMSwC/fJ63 abpvUSTxs9tzHw4DzyD1cdsyl7vTWSEFmK1gWkPer8bQFSd8z47DvO2rSdFP2w9QtWhk Hu3fRuuCdtcrRL3gomSvKrD0UF8oB97ZqVckSAODlZGAIAZrDuaf7tu28+A7Muwlz9Ap a6FpnEP87zwO8WJOHbx2qEk03jLUALu7EIll9BuBVLQxtfZanRlMPCDQU6vUc1NyD/yW R7pwlz/HjgqmBPG4TqugVXAInszF0JJgdMX5NKM5iBDPiovQG2HHxQNW6vqYvBIhPfxn oZvA== X-Gm-Message-State: APjAAAU9wHdJWuLYjujLz+VKrfShtfsoivmv4stAKO1vICRY6LzxqZFg CsWeqc76Wtbfl76hP59pSK5yE/wAuGDaR7bFxf4= X-Received: by 2002:a50:a53a:: with SMTP id y55mr122610228edb.147.1564758886126; Fri, 02 Aug 2019 08:14:46 -0700 (PDT) MIME-Version: 1.0 References: <20190802083541.12602-1-hslester96@gmail.com> In-Reply-To: From: Willem de Bruijn Date: Fri, 2 Aug 2019 11:14:10 -0400 Message-ID: Subject: Re: [PATCH v2 1/2] cxgb4: sched: Use refcount_t for refcount To: Chuhong Yuan Cc: Vishal Kulkarni , "David S . Miller" , Network Development , linux-kernel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 2, 2019 at 11:10 AM Chuhong Yuan wrote: > > Willem de Bruijn =E4=BA=8E2019=E5=B9=B4= 8=E6=9C=882=E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=8810:53=E5=86=99=E9= =81=93=EF=BC=9A > > > > On Fri, Aug 2, 2019 at 10:27 AM Chuhong Yuan wro= te: > > > > > > Willem de Bruijn =E4=BA=8E2019=E5= =B9=B48=E6=9C=882=E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=889:40=E5=86= =99=E9=81=93=EF=BC=9A > > > > > > > > On Fri, Aug 2, 2019 at 4:36 AM Chuhong Yuan = wrote: > > > > > > > > > > refcount_t is better for reference counters since its > > > > > implementation can prevent overflows. > > > > > So convert atomic_t ref counters to refcount_t. > > > > > > > > > > Signed-off-by: Chuhong Yuan > > > > > --- > > > > > Changes in v2: > > > > > - Convert refcount from 0-base to 1-base. > > > > > > > > This changes the initial value from 0 to 1, but does not change the > > > > release condition. So this introduces an accounting bug? > > > > > > I have noticed this problem and have checked other files which use re= fcount_t. > > > I find although the refcounts are 1-based, they still use > > > refcount_dec_and_test() > > > to check whether the resource should be released. > > > One example is drivers/char/mspec.c. > > > Therefore I think this is okay and do not change the release conditio= n. > > > > Indeed it is fine to use refcount_t with a model where the initial > > allocation already accounts for the first reference and thus > > initializes with refcount_set(.., 1). > > > > But it is not correct to just change a previously zero initialization > > to one. As now an extra refcount_dec will be needed to release state. > > But the rest of the code has not changed, so this extra decrement will > > not happen. > > > > For a correct conversion, see for instance commits > > > > commit db5bce32fbe19f0c7482fb5a40a33178bbe7b11b > > net: prepare (struct ubuf_info)->refcnt conversion > > > > and > > > > commit c1d1b437816f0afa99202be3cb650c9d174667bc > > net: convert (struct ubuf_info)->refcnt to refcount_t > > > > The second makes a search-and-replace style API change like your > > patches (though also notice the additional required #include). > > > > Thanks for your examples! > I will fix the #include in those no base changed patches. > > > But the other patch is needed first to change both the initial > > atomic_set *and* at least one atomic_inc, to maintain the same > > reference count over the object's lifetime. > > > > That change requires understanding of the object's lifecycle, so I > > suggest only making those changes when aware of that whole data path. > > I think I had better focus on the 1-based cases first. Yes, sounds good. And please try a single driver first and get that accepted, before moving on to multiple concurrent submissions.