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]
Message-ID: <AANLkTi=Jx7OQGVGYhYU+wLkB2=6BwieR9kX-N9sLxVi2@mail.gmail.com>
Date:	Tue, 16 Nov 2010 16:56:26 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Neil Brown <neilb@...e.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>
Subject: Re: [PATCH] support polling of /proc/swaps

On Mon, Nov 15, 2010 at 04:44, Neil Brown <neilb@...e.de> wrote:
> On Wed, 20 Oct 2010 01:25:47 +0200 Kay Sievers <kay.sievers@...y.org> wrote:
>> On Tue, 2010-10-19 at 15:31 -0700, Andrew Morton wrote:
>> > On Tue, 19 Oct 2010 11:19:16 +0200
>> > Kay Sievers <kay.sievers@...y.org> wrote:
>>
>> > It's a bit sad that we have to add quite a pile of infrastructure to
>> > make a procfs file pollable.  I wonder if it's possible to provide some
>> > core support for this, and reduce the amount of code at each particular
>> > handler site.
>>
>> You mean something like adding the event counter to the seq_file? There
>> is /proc/self/mounts,mountinfo and /proc/swaps so far, I think.
>
> And /proc/mdstat.
>
> In /proc/mdstat I do something a little bit different.  I only update the
> per-file event number when reading the first byte of the file, rather than
> when poll returns POLL_PRI.
> This is somewhat more robust.  In general select/poll will continue returning
> a 'ready' status until the program performs some action (typically read or
> write) which makes the fd not ready any more.
>
> With your code (which I think is the same as /proc/mounts) you get at most 1
> notification per change so you have to be careful not to miss it.  It is like
> an edge triggered interrupt rather than level triggered.
>
> So if this were extracted into the seqfile library (which is probably a good
> idea), I'd like to see a suitably robust version used.

Sure, sounds good to me to have that available in the seq file. The
current logic works fine so far, but always returning from poll(),
until data is actually read(), sounds nice.

You want to give it a try how stuff moved into seq_file would look like?

Kay
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ