Re: [PATCH 1/4] l2cap endianness annotations

[Al Viro <viro@ftp.linux.org.uk>]

On Mon, Oct 16, 2006 at 01:39:03AM +0200, Marcel Holtmann wrote:
> this data structure is visible to the userspace (via the Bluetooth
> library headers). Do we annotate them, too?

Yes. linux/types.h is exported header and it defines all endian types.
 
> > @@ -221,7 +221,7 @@ struct l2cap_pinfo {
> >  
> >  	__u8		ident;
> >  
> > -	__u16		sport;
> > +	__le16		sport;
> >  
> >  	struct l2cap_conn	*conn;
> >  	struct sock		*next_c;
> 
> These are internal. We should have to annotate them. They should store
> it in host order. If not, than that is the problem.

They do not.  Trivial search in vanilla tree shows
                for (psm = 0x1001; psm < 0x1100; psm += 2)
                        if (!__l2cap_get_sock_by_addr(psm, src)) {
                                l2cap_pi(sk)->psm   = htobs(psm);
                                l2cap_pi(sk)->sport = htobs(psm);
                                err = 0;
                                break;
                        }

which is very definitely not putting a host-endian there.  You can
switch it to host-endian, of course, but then you have to modify
at least that place.
 
> > @@ -1533,7 +1533,7 @@ static inline int l2cap_config_req(struc
> >  	if (!(sk = l2cap_get_chan_by_scid(&conn->chan_list, dcid)))
> >  		return -ENOENT;
> >  
> > -	l2cap_parse_conf_req(sk, req->data, cmd->len - sizeof(*req));
> > +	l2cap_parse_conf_req(sk, req->data, __le16_to_cpu(cmd->len) - sizeof(*req));
> 
> I have to look into this change. It basically means that this code never
> worked on big endian systems, but it actually does.

You are misreading it.  Old code flipped cmd->len in place in the caller.
New one doesn't.