linux-kernel - Re: [PATCH 19/21] ceph: ioctls

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20091002163618.GN1656@one.firstfloor.org>
Date:	Fri, 2 Oct 2009 18:36:18 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Sage Weil <sage@...dream.net>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	yehuda@...dream.net
Subject: Re: [PATCH 19/21] ceph: ioctls

> Yes.  I suspect an explicit
> 
> 	struct in6_addr osd_addr;
> 	__be16 osd_port;
> 
> makes more sense.  Then legacy IPv4 addresses can just be represented as 
> ::ffff:1.2.3.4.  That seems like the simplest route?

You would need to decide internally then if you want to use
the ipv6 socket API (requiring ipv6 to be loaded) or map 
manually. Using af_family might be cleaner.

> 
> I should similarly update the struct ceph_entity_addr as well (it also 
> embeds a sockaddr_in).  And/or embed that struct here.

You could also use struct sockaddr_storage, it's designed to contain arbitary
address types (basically it has a lot of padding)

Trap: if you ever copy it out you have to make sure to not leak
kernel memory in the padding of course.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/