To: Richard Weinberger <richard@nod.at>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>,
        "Theodore Ts'o" <tytso@mit.edu>, Harald Hoyer <harald@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
References: <21824.5086.446831.189915@quad.stoffel.home>
 <5540D2F9.2010704@redhat.com>
 <CAFLxGvzz3ac19J=dC_gWrrY=BG4h-LO+uRn2rOr1eWyVnk3vzg@mail.gmail.com>
 <5540DEEB.2060405@redhat.com> <5540E0C7.3050106@nod.at>
 <5540E432.9020606@redhat.com> <5540E4D9.6000007@nod.at>
 <5540E684.4070606@redhat.com> <5540E821.8050204@nod.at>
 <5540F081.9090005@redhat.com> <20150429150341.GA12374@thunk.org>
 <5540F6E3.8000706@gmail.com> <871tj2ouk2.fsf%l.stelmach@samsung.com>
 <5541F209.8070302@nod.at> <87wq0tor57.fsf%l.stelmach@samsung.com>
 <55420685.8080607@nod.at> <87oam5olpu.fsf%l.stelmach@samsung.com>
 <55421EBB.2010500@nod.at> <87k2wtokl8.fsf%l.stelmach@samsung.com>
 <554223CE.7070704@nod.at>
From: =?utf-8?Q?=C5=81ukasz_Stelmach?= <l.stelmach@samsung.com>
Date: Thu, 30 Apr 2015 16:52:27 +0200
In-reply-to: <554223CE.7070704@nod.at>
Message-id: <878ud9oehg.fsf%l.stelmach@samsung.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
MIME-version: 1.0
Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256;
 protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3700
Lines: 89

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

It was <2015-04-30 czw 14:45>, when Richard Weinberger wrote:
> Am 30.04.2015 um 14:40 schrieb =C5=81ukasz Stelmach:
>> It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
>>> Am 30.04.2015 um 14:16 schrieb =C5=81ukasz Stelmach:
>>>> It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
>>>>> Am 30.04.2015 um 12:19 schrieb =C5=81ukasz Stelmach:
>>>>>> It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
>>>>>>> Am 30.04.2015 um 11:05 schrieb =C5=81ukasz Stelmach:
>>>>>>>> Regardless, of initrd issues I feel there is a need of a local IPC
>>>>>>>> that is more capable than UDS.=20
>> [...]
>>>>>> For example, a service can't aquire credentials of a client process =
that
>>>>>> actually sent a request (it can, but it can't trust them). The servi=
ce
>>>>>> can't be protected by LSM on a bus that is driven by dbus-daemon. Ye=
s,
>>>>>> dbus-daemon, can check client's and srevice's labels and enforce a
>>>>>> policy but it is going to be the daemon and not the LSM code in the
>>>>>> kernel.
>>>>>
>>>>> That's why I said we can think of new kernel features if they are
>>>>> needed.  But they current sink or swim approach of kdbus folks is also
>>>>> not the solution.  As I said, if dbus-daemon utilizes the kernel
>>>>> interface as much as possible we can think of new features.
>>>>
>>>> What kernel interfaces do you suggest to use to solve the issues
>>>> I mentioned in the second paragraph: race conditions, LSM support (for
>>>> example)?
>>>
>>> The question is whether it makes sense to collect this kind of meta dat=
a.
>>> I really like Andy and Alan's idea improve AF_UNIX or revive AF_BUS.
>>=20
>> Race conditions have nothing to do with metadata. Neither has LSM
>> support.
>
> Sorry, I thought you mean the races while collecting metadata in userspac=
e...

My bad, some reace conditions *are* associated with collecting metadata
but ont all. It is impossible (correct me if I am wrong) to implement
reliable die-on-idle with dbus-daemon.

>> AF_UNIX with multicast support wouldn't be AF_UNIX anymore.
>>=20
>> AF_BUS? I haven't followed the discussion back then. Why do you think it
>> is better than kdbus?
>
> Please see https://lwn.net/Articles/641278/

Thanks. If I understand correctly, the author suggests using EBPF on a
receiveing socket side for receiving multicast messages. This is nice if
you care about introducing (or not) (too?) much of new code. However,
AFAICT it may be more computationally complex than Bloom filters because
you need to run EBPF on every receiving socket instead of getting a list
of a few of them to copy data to. Of course for small number of
receivers the "constant" cost of running the Bloom filter may be higher.

Kind regards,
=2D-=20
=C5=81ukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVQkGrAAoJELCuHpyYpYAQiqEH/Aspkgwtg2R2kACRDRlWg/dr
sSxuYVwTmsvCdMxIlSDIUaFy9M5i+/Dj2gSZDsltM+4BZ3h5L3stuvYg5gu4o1A+
jrcxa6/NYR90Zm4BUz/BYJFv0PQ+86MehdbatcXsT8G4Bk+gbaanS/v8JqHTR46k
XsYTC1N9m55Ymn+i9v5MDMDrjxdFQXWC2HYN/pCsxUNUN6fqtV0MRFwjrHZRxMWz
mFC+aEtbkMjQjXPNEyoSzMl5ZThG/DEQ2zuns5YtY0eb2FZnI4h78j4e+sTVXs1x
wjbev4PZnwW4OugpZx0gfYY6yte+DLIgJIEwXwqBn3xWF9tR9HzMBn11K3Q165Y=
=w3jC
-----END PGP SIGNATURE-----
--=-=-=--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/