linux-kernel - Re: [PATCH 0/5][V2] FS: userspace notification of errors

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]

Date:	Thu, 11 Jun 2009 15:26:39 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Denis Karpov <ext-denis.2.karpov@...ia.com>
Cc:	hirofumi@...l.parknet.co.jp, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, adrian.hunter@...ia.com,
	artem.bityutskiy@...ia.com, akpm@...ux-foundation.org
Subject: Re: [PATCH 0/5][V2] FS: userspace notification of errors

On Thu, Jun 11, 2009 at 14:24, Denis Karpov<ext-denis.2.karpov@...ia.com> wrote:

> There were several objections to uevent usage, mostly with argument that
> uevents are meant to be used within a device context. One might argue that
> uevents are tied to kobjects that are not only used to represent devices,
> but also for other things (/sys/modules, /sys/fs, /sys/firmware).

No, the objection was to use the underlying *device* as the source to
raise filesystem events. I don't think there are problems in general
with objects in /sys/fs/ sending events.

But, the remaining questions here are:
Do we really want superblocks exported in the global,
non-namespace-aware /sys? It might be wrong to export stuff from other
namespaces for filesytems which are irrelevant, and not even visible.
I'm not sure about this, and it needs careful evaluation. We once had
filesystem mount/umount uevents on block devices, and we needed to
remove them for that namespace reason.

If we go that road, do we want all filesystems export their
superblocks here, like e.g. /sys/fs/super/<maj>:<min>/, or is this
custom fs-specific, like this patch does.

> What is wrong with using uevents otherwise? What would be another way to
> asyncronousely notify userspace of things happening in kernel, other
> than though pseudo filesystem files (procfs, sysfs)?

The question is how to relay error details, and how to transport that
information to userpace. Uevents have no state, and the information is
lost after the event. Uevents can not block, they need to finish in
userspace immediately, you can not queue the up or anything else, it
would block other operations. Uevents can _never_ be used to transport
high frequent event streams. They might render the entire system
unusable, if you have lots of devices and many errors.

They could be used to get attention when a superblock does a one-time
transition from "clean" to "error", everything else would just get us
into serious trouble later.

Thanks,
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/