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
| ||
|
Message-ID: <87jzssel0p.fsf@intel.com> Date: Thu, 14 Sep 2023 10:12:54 -0700 From: Vinicius Costa Gomes <vinicius.gomes@...el.com> To: Richard Cochran <richardcochran@...il.com> Cc: Xabier Marquiegui <xabier.marquiegui@...il.com>, alex.maftei@....com, chrony-dev@...ony.tuxfamily.org, davem@...emloft.net, horms@...nel.org, mlichvar@...hat.com, netdev@...r.kernel.org, ntp-lists@...tcorallo.com, reibax@...il.com, rrameshbabu@...dia.com, shuah@...nel.org Subject: Re: [PATCH net-next v2 2/3] ptp: support multiple timestamp event readers Hi Richard, Richard Cochran <richardcochran@...il.com> writes: > On Wed, Sep 13, 2023 at 02:25:48PM -0700, Vinicius Costa Gomes wrote: > >> Taking a quick look, it seems that you would have to change 'struct >> posix_clock_file_operations' to also pass around the 'struct file' of >> the file being used. > > And let drivers compare struct file pointers from different consumers? > That was the first idea, not very good I admit. What you said below sounds better, more "final product". >> That way we can track each user/"open()". And if one program decides >> that it needs to have have multiple fds with different masks, and so >> different queues, it should just work. >> >> What do you think? > > See posix-clock.c : posix_clock_open() > > When the file is opened, the fp->private_data is used to track the > posix_clock that was registered as a character device by the ptp > clock instance. > > That character device may be opened multiple times, each time there is > a unique fp, but fp->private_data points to the same ptp clock instance. > > So the information of which fp is being read() is lost. yeah, that's the core issue. > > Looks like you will have to re-work posix-clock.c to allow drivers to > provide their own "private" data populated during posix_clock_operations::open() > > Needs thought... > Cheers, -- Vinicius
Powered by blists - more mailing lists