netdev - Re: [PATCH net-next] ptp: increase the maximum number of clocks

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] [day] [month] [year] [list]

Date:	Tue, 26 Mar 2013 19:44:33 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	Jiri Benc <jbenc@...hat.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Ben Hutchings <bhutchings@...arflare.com>
Subject: Re: [PATCH net-next] ptp: increase the maximum number of clocks

On Tue, Mar 26, 2013 at 10:48:36AM +0100, Jiri Benc wrote:
> On Mon, 25 Mar 2013 19:51:20 +0100, Richard Cochran wrote:
> > While that might work for the PTP ioctls, it won't for the main
> > clock_gettime/settime/adjtime call. As you wrote below, these take a
> > dynamic clockid_t (which comes from a file descriptor), and so each
> > device needs its own, unique file system node.
> 
> They need an unique file descriptor, not an unique file. There's nothing
> preventing you from opening the same file multiple times, using each
> obtained file descriptor to access a different PHC. Sure, there is
> currently no place to store a per-fd data in posix-clock implementation
> but that could be added.

Assume you have multiple clocks in the system. You open /dev/ptp, and
you get a FD to be passed to clock_gettime. But *which* clock's time
should be read?

(An extra ioctl to choose the active clock seems a bit gross to me.)

> > For better or worse, we are stuck with char devs, unless we want to
> > redo the clock_xyz API. I certainly don't want to. We can have over a
> > million PTP clocks on a single major number. That should be enough.
> > 
> > IIRC, it is possible to grow the range of minor numbers
> > incrementally. Perhaps you could take a look at that?
> 
> That was what I was originally thinking about. But I don't like it much
> - the overhead will increase significantly with increasing number of
> devices, as the chrdev allocations for a given major are kept in a
> linked list which has to be completely traversed on each allocation.
> We'd also need to replace the ptp_clocks_map with a different data
> structure (e.g. a linked list of bitmaps if we allocate minors in
> chunks to alleviate the chrdev allocation overhead), not helping the
> overhead.

How about using idr and then, at each clock registration, just
increase the range of minors to include the new number?

I wouldn't worry about the overhead at allocation time. It is one time
only, during device registration, and so is not performance critical.

Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html