Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Li zeming <zeming@nfschina.com>
CC:     Jeff Layton <jlayton@kernel.org>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        Anna Schumaker <anna@kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sunrpc: svc: Remove unnecessary (void*) conversions
Thread-Topic: [PATCH] sunrpc: svc: Remove unnecessary (void*) conversions
Thread-Index: AQHY7ySNZudTEDZRlUCQuYzh7drgj64tJx0AgAAFBoA=
Date:   Thu, 3 Nov 2022 13:07:24 +0000
Message-ID: <52658929-14AE-49AB-80DE-F0C68DD29D3D@oracle.com>
References: <20221103013510.3062-1-zeming@nfschina.com>
 <229b424a647bfbd18942eefef4cbf6332607ca2b.camel@kernel.org>
In-Reply-To: <229b424a647bfbd18942eefef4cbf6332607ca2b.camel@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?TZiX/ahCfasZ6bIYweBLh/GTcIehykz7Czi+14VvL9/2PHOjEuv5ObmMsUQW?=
 =?us-ascii?Q?+jpSk/wkFxCxkvUtwwcqr0TnbqOQ4GFhc2xguLol/XfiVuXwNWKwEWZ8M62K?=
 =?us-ascii?Q?WGMy98owaV8RRy60WPJQV8fTceDeKAASXQ1mI5Kg/nLfSOagqSLuUq52GrnF?=
 =?us-ascii?Q?V1RrcLeKxgEfM63GxKxJCLKkKj1CK6rIfStYkSE6lZcVg0Y3rViTZ1bTRMnV?=
 =?us-ascii?Q?d6J4ITZktgEsXjX0Iy9me9tDJi//efJZ3qGGhTz9ERsgFV+p7C4c5EWr0NED?=
 =?us-ascii?Q?vSrftIaQT5C2cFr+OABquXyz9VsDnWH86dsW1zUC1iFsqOGgLXMN9u8gVD8Q?=
 =?us-ascii?Q?rbBpN3DM1Xm6gY+OYdd1fSv62BBZMLIXZOJQzF4nvq2JMBOPa5410J95ZntY?=
 =?us-ascii?Q?NtK+xtWKH6Rg8TwFyjNYEBcS4ApzRlvOEISb2D5L93KSUGXdaoVMWkMPQWE+?=
 =?us-ascii?Q?be8IJOFBhU+Xt6i3nIcHksn9Gt9RXQqM285qAnapjXnfRQ0VUIOLM59iCpPC?=
 =?us-ascii?Q?aM7uMY024DmoUfPVdvXZoNNhAmEuebufsUSYWS0pi4k8L5rRPNqLMoG2oRyG?=
 =?us-ascii?Q?uZ7dCzJ0R0hxuvpmhp41/5jGTHQR+lkZkgWH48EariCe6gac9jKW3Dxbwk5y?=
 =?us-ascii?Q?od9vW6AHH7dFcNrDupci+sllirAquQ/914pOG/fuE/fOe05daOzTj8zJlqGa?=
 =?us-ascii?Q?Np8GxyUYRD7GzgM7+bHNiXE1NG98KS9QiJJST1CvuGPK268wVPi+zgMOxuef?=
 =?us-ascii?Q?2DZbY2VG4YRveLmlZ6gs8iakYetkGD9j9zQNfWq+hx4epL1bsgrnqB2WL3j1?=
 =?us-ascii?Q?/zayVipexWgmRp0x9P4hWN1uI2GBjQE3KAZEtxr+bmqMftXzDQV5knRFzn5/?=
 =?us-ascii?Q?BWJT1ig8B/UAn95McJZpt41rOwWidHZ0vnEQ8VkoKRDRtL8lXZNqbJqAbuKK?=
 =?us-ascii?Q?O2cN9/Xv+nt1uQfrlcVFfGw00jekerRkBQzj+/pmms8VCUIqYMyVASqpikMs?=
 =?us-ascii?Q?msx14ugAcERwb3nDS0LmwLU9zRk8QJlQv3ZDwewG94oRLRoluGjyN4aV31Ms?=
 =?us-ascii?Q?ZmLLbBZ9vF7R1EJNo942ayUY2HKpl7KUCj+xomNLgAcnJDwIioyIaLRi+YCy?=
 =?us-ascii?Q?nWZIJ5it1wZm2sV2buIsU5EEb70RWa/66iK5tvYqP6fR4UCEHcrGfriIS5J4?=
 =?us-ascii?Q?SVCd42IH2vuAMxUqZTu6mUxTf+GBjNRrvJOMFVM7G1C5hFuiMhmMVLtCpxqJ?=
 =?us-ascii?Q?e5mCrHJDKWCXuYX2ruP+9Z4EDbhQcyDxo3dwQjrzS8MRy0RaYAkfuQTH7w/5?=
 =?us-ascii?Q?3irme8g4DIJ+iME5aj6xbQx0CPNY8Q27T8QHU+MGqQlb0oE/x8J410JfT2YY?=
 =?us-ascii?Q?6IT2og0+JSHe9Unb9mWCJ7YrQeyrHMQh3XT/hr25Jsv1qrj4raDhL4TkH7BM?=
 =?us-ascii?Q?aWpxlKXdtzqlD9BF3KIaV4+HGoWXiP9gVp1eaiphFYe23QQlzDOqJydcYYDC?=
 =?us-ascii?Q?rNJk9gTl5Wb/YqOcAGR5qYZJjbznDXCdZwk3K1zTyrztPLLmh40XdlSf5m9m?=
 =?us-ascii?Q?GmQXNASsnKoWIhXNZEjfMO1Wwok6wDCZeW5iCRv+JC+IQIBZqDbpRZSYtwxd?=
 =?us-ascii?Q?cw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0154365F4F71F74D87C92E39DBCB920D@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ad12c70b-ceac-43f7-48fb-08dabd9c5999
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2022 13:07:24.1799
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: S2PFDUR8ggqBl+4T8mhVyfMkOWQ63vgzlQDsw2Z08pmXSZocHFWEKwb06DS319JPoJjlpqfsmDwA/NHp1ckORA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB5136
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-03_04,2022-11-03_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 bulkscore=0
 suspectscore=0 phishscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2211030090
X-Proofpoint-ORIG-GUID: NHrYJjhLFR0Ra7Kt2iAOsN8e6F27FaSo
X-Proofpoint-GUID: NHrYJjhLFR0Ra7Kt2iAOsN8e6F27FaSo
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE 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: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Nov 3, 2022, at 8:49 AM, Trond Myklebust <trondmy@kernel.org> wrote:
>=20
> On Thu, 2022-11-03 at 09:35 +0800, Li zeming wrote:
>> The iov_base pointer does not need to cast the type.
>>=20
>> Signed-off-by: Li zeming <zeming@nfschina.com>
>> ---
>>  include/linux/sunrpc/svc.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>=20
>> diff --git a/include/linux/sunrpc/svc.h b/include/linux/sunrpc/svc.h
>> index daecb009c05b..4b0eead91c94 100644
>> --- a/include/linux/sunrpc/svc.h
>> +++ b/include/linux/sunrpc/svc.h
>> @@ -222,7 +222,7 @@ static inline __be32 svc_getu32(struct kvec *iov)
>> =20
>>  static inline void svc_ungetu32(struct kvec *iov)
>>  {
>> -       __be32 *vp =3D (__be32 *)iov->iov_base;
>> +       __be32 *vp =3D iov->iov_base;
>>         iov->iov_base =3D (void *)(vp - 1);
>>         iov->iov_len +=3D sizeof(*vp);
>>  }
>=20
> If you're going to submit a patch just in order to strip unnecessary
> casts, then why are you leaving the equally unnecessary cast in the
> next line?
>=20
> That said, why waste time "fixing" an inlined function that is not
> actually called anywhere in the kernel? svc_ungetu32() should just be
> removed.

Sorry for the delay, I was expecting an electrical service outage
here at home yesterday, so the lab was powered off.

So, Li, can you drop this one, and instead send a patch that removes
the definition of svc_ungetu32 ?


--
Chuck Lever