linux-kernel - Re: [RFC PATCH 17/35] libceph, rbd: Use ceph

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2680646.1742336396@warthog.procyon.org.uk>
Date: Tue, 18 Mar 2025 22:19:56 +0000
From: David Howells <dhowells@...hat.com>
To: Viacheslav Dubeyko <Slava.Dubeyko@....com>
Cc: dhowells@...hat.com, Alex Markuze <amarkuze@...hat.com>,
    "slava@...eyko.com" <slava@...eyko.com>,
    "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
    "idryomov@...il.com" <idryomov@...il.com>,
    "jlayton@...nel.org" <jlayton@...nel.org>,
    "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
    "ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>,
    "dongsheng.yang@...ystack.cn" <dongsheng.yang@...ystack.cn>,
    "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 17/35] libceph, rbd: Use ceph_databuf encoding start/stop

Viacheslav Dubeyko <Slava.Dubeyko@....com> wrote:

> > -		ceph_encode_string(&p, end, buf, len);
> > +		BUG_ON(p + sizeof(__le32) + len > end);
> 
> Frankly speaking, it's hard to follow why sizeof(__le32) should be in the
> equation. Maybe, it make sense to introduce some constant? The name of
> constant makes understanding of this calculation more clear.

Look through the patch.  It's done all over the place, even on parts I haven't
touched.  However, it's probably because of the way the string is encoded
(4-byte LE length followed by the characters).

It probably would make sense to use a calculation wrapper for this.  I have
this in fs/afs/yfsclient.c for example:

	static size_t xdr_strlen(unsigned int len)
	{
		return sizeof(__be32) + round_up(len, sizeof(__be32));
	}

> > +	BUG_ON(sizeof(__le64) + sizeof(__le32) + wsize > req->request->front_alloc_len);
> 
> The same problem is here. It's hard to follow to this check by involving
> sizeof(__le64) and sizeof(__le32) in calculation. What these numbers mean here?

Presumably the sizes of the protocol elements in the marshalled data.  If you
want to clean all those up in some way, I can add your patch into my
series;-).

David