From gsgatlin@ncsu.edu  Fri Jun  3 19:31:09 2016
From: gsgatlin@ncsu.edu (Gary Gatling)
Date: Fri, 3 Jun 2016 14:31:09 -0400
Subject: [OpenAFS-devel] Re: having trouble compiling openafs kernel module in kernel 4.5
In-Reply-To: <CAG5Ck-7X20pE5JhU+z8cxb7pTKhZ3A0KrHu1M+vnk2fDK-_irA@mail.gmail.com>
References: <CAG5Ck-7X20pE5JhU+z8cxb7pTKhZ3A0KrHu1M+vnk2fDK-_irA@mail.gmail.com>
Message-ID: <CAG5Ck-6UTdSvN8Fz+F=4KjuTP6cNHHSj3FWE5b9XeGx8Gi7k=Q@mail.gmail.com>

--001a113b72a23a090b053463ed31
Content-Type: text/plain; charset=UTF-8

Has there been any progress on kernel 4.5? fedora 23
shipped 4.5.5-201.fc23.x86_64 today and my openafs is broke. This makes me
very sad.

When I try to compile it I get these errors:

https://paste.fedoraproject.org/374192/14649784/

I am using:

0001-Linux-3.13-Check-return-value-from-bdi_init.patch
0002-Linux-4.5-no-highmem-in-symlink-ops.patch
0003-Linux-4.5-get_link-instead-of-follow_link-put_link.patch
0005-Linux-4.5-don-t-access-i_mutex-directly.patch

with openafs-1.6.18-src.tar.bz2

Am I missing some patches?

Thanks for any ideas anyone may have on how to compile openafs on 4.5
kernel. I know its possible since Arch Linux pulled it off.

On Wed, Apr 6, 2016 at 1:24 PM, Gary Gatling <gsgatlin@ncsu.edu> wrote:

> Here is my build log:
>
> http://fpaste.org/350505/99628291/
>
> This is in fedora 24 alpha version which will be released in June.
>
> It seems to have problems with symlinks somehow.
>
> Any one have any ideas about how it could be patched? The kernel version
> is 4.5.0-302.fc24.x86_64.
>
> Thanks,
>
>

--001a113b72a23a090b053463ed31
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Has there been any progress on kernel 4.5? fedora 23 shipp=
ed=C2=A04.5.5-201.fc23.x86_64 today and my openafs is broke. This makes me =
very sad.<div><br></div><div>When I try to compile it I get these errors:</=
div><div><br></div><div><a href=3D"https://paste.fedoraproject.org/374192/1=
4649784/">https://paste.fedoraproject.org/374192/14649784/</a><br></div><di=
v><br></div><div>I am using:</div><div><br></div><div>0001-Linux-3.13-Check=
-return-value-from-bdi_init.patch<br></div><div>0002-Linux-4.5-no-highmem-i=
n-symlink-ops.patch<br></div><div>0003-Linux-4.5-get_link-instead-of-follow=
_link-put_link.patch<br></div><div>0005-Linux-4.5-don-t-access-i_mutex-dire=
ctly.patch<br></div><div><br></div><div>with=C2=A0openafs-1.6.18-src.tar.bz=
2</div><div><br></div><div>Am I missing some patches?</div><div><br></div><=
div>Thanks for any ideas anyone may have on how to compile openafs on 4.5 k=
ernel. I know its possible since Arch Linux pulled it off.</div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Apr 6, 2016 at=
 1:24 PM, Gary Gatling <span dir=3D"ltr">&lt;<a href=3D"mailto:gsgatlin@ncs=
u.edu" target=3D"_blank">gsgatlin@ncsu.edu</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">Here is my build log:<div><br><div=
><a href=3D"http://fpaste.org/350505/99628291/" target=3D"_blank">http://fp=
aste.org/350505/99628291/</a><br></div><div><br></div><div>This is in fedor=
a 24 alpha version which will be released in June.</div><div><br></div><div=
>It seems to have problems with symlinks somehow.</div><div><br></div><div>=
Any one have any ideas about how it could be patched? The kernel version is=
=C2=A04.5.0-302.fc24.x86_64.</div><div><br></div><div>Thanks,</div><div><br=
></div></div></div>
</blockquote></div><br></div>

--001a113b72a23a090b053463ed31--

From stephan.wiesand@desy.de  Fri Jun  3 20:13:16 2016
From: stephan.wiesand@desy.de (Stephan Wiesand)
Date: Fri, 3 Jun 2016 21:13:16 +0200
Subject: [OpenAFS-devel] Re: having trouble compiling openafs kernel module in kernel 4.5
In-Reply-To: <CAG5Ck-6UTdSvN8Fz+F=4KjuTP6cNHHSj3FWE5b9XeGx8Gi7k=Q@mail.gmail.com>
References: <CAG5Ck-7X20pE5JhU+z8cxb7pTKhZ3A0KrHu1M+vnk2fDK-_irA@mail.gmail.com> <CAG5Ck-6UTdSvN8Fz+F=4KjuTP6cNHHSj3FWE5b9XeGx8Gi7k=Q@mail.gmail.com>
Message-ID: <A9E68172-D61E-4CB3-871A-4FB193DDD7C2@desy.de>

On Jun 3, 2016, at 20:31 , Gary Gatling wrote:

> Has there been any progress on kernel 4.5? fedora 23
> shipped 4.5.5-201.fc23.x86_64 today and my openafs is broke. This =
makes me
> very sad.
>=20
> When I try to compile it I get these errors:
>=20
> https://paste.fedoraproject.org/374192/14649784/
>=20
> I am using:
>=20
> 0001-Linux-3.13-Check-return-value-from-bdi_init.patch
> 0002-Linux-4.5-no-highmem-in-symlink-ops.patch
> 0003-Linux-4.5-get_link-instead-of-follow_link-put_link.patch
> 0005-Linux-4.5-don-t-access-i_mutex-directly.patch
>=20
> with openafs-1.6.18-src.tar.bz2
>=20
> Am I missing some patches?
>=20
> Thanks for any ideas anyone may have on how to compile openafs on 4.5
> kernel. I know its possible since Arch Linux pulled it off.

Alas, if so, they haven't bothered submitting the magic patch to =
gerrit.openafs.org. The changes under =
https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:master+t=
opic:linux45 are all we have. I'll take your message as a report that =
those changes are not sufficient to cope with Linux 4.5. It makes me =
very sad.

> On Wed, Apr 6, 2016 at 1:24 PM, Gary Gatling <gsgatlin@ncsu.edu> =
wrote:
>=20
>> Here is my build log:
>>=20
>> http://fpaste.org/350505/99628291/
>>=20
>> This is in fedora 24 alpha version which will be released in June.
>>=20
>> It seems to have problems with symlinks somehow.
>>=20
>> Any one have any ideas about how it could be patched? The kernel =
version
>> is 4.5.0-302.fc24.x86_64.
>>=20
>> Thanks,


From lass@mail.upb.de  Fri Jun  3 20:57:01 2016
From: lass@mail.upb.de (Michael =?ISO-8859-1?Q?La=DF?=)
Date: Fri, 03 Jun 2016 21:57:01 +0200
Subject: [OpenAFS-devel] Re: having trouble compiling openafs kernel
 module in kernel 4.5
In-Reply-To: <A9E68172-D61E-4CB3-871A-4FB193DDD7C2@desy.de>
References: <CAG5Ck-7X20pE5JhU+z8cxb7pTKhZ3A0KrHu1M+vnk2fDK-_irA@mail.gmail.com>
 <CAG5Ck-6UTdSvN8Fz+F=4KjuTP6cNHHSj3FWE5b9XeGx8Gi7k=Q@mail.gmail.com>
 <A9E68172-D61E-4CB3-871A-4FB193DDD7C2@desy.de>
Message-ID: <1464983821.1401.10.camel@mail.upb.de>

Hi,

Am Freitag, den 03.06.2016, 21:13 +0200 schrieb Stephan Wiesand:
> On Jun 3, 2016, at 20:31 , Gary Gatling wrote:
> > Thanks for any ideas anyone may have on how to compile openafs on 4.5
> > kernel. I know its possible since Arch Linux pulled it off.
> 
> Alas, if so, they haven't bothered submitting the magic patch to
> gerrit.openafs.org. The changes under
> https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:mas
> ter+topic:linux45 are all we have. I'll take your message as a report
> that those changes are not sufficient to cope with Linux 4.5. It
> makes me very sad.

As I am maintaining the Arch Linux package: There is no magic patch,
only the aforementioned patches are applied (gerrit 12264, 12265,
12268, 12274) and the kernel module compiles and works (as far as I can
tell) with Linux 4.5.4.

The first issue in the linked compile log is the following:
> /home/gsgatlin/redhat/sources/openafs-1.6.18/src/libafs/MODLOAD-4.5.5-201.fc23.x86_64-MP/osi_vnodeops.c: In function ‘afs_linux_follow_link’:
> /home/gsgatlin/redhat/sources/openafs-1.6.18/src/libafs/MODLOAD-4.5.5-201.fc23.x86_64-MP/osi_vnodeops.c:1935:5: error: implicit declaration of function ‘nd_set_link’ [-Werror=implicit-function-declaration]
>      nd_set_link(nd, name);

This particular error occurs if 0003-Linux-4.5-get_link-instead-of-
follow_link-put_link.patch (gerrit 12265) is not applied.

Cheers,
Michael

From gsgatlin@ncsu.edu  Fri Jun  3 21:27:39 2016
From: gsgatlin@ncsu.edu (Gary Gatling)
Date: Fri, 3 Jun 2016 16:27:39 -0400
Subject: [OpenAFS-devel] Re: having trouble compiling openafs kernel
 module in kernel 4.5
In-Reply-To: <1464983821.1401.10.camel@mail.upb.de>
References: <CAG5Ck-7X20pE5JhU+z8cxb7pTKhZ3A0KrHu1M+vnk2fDK-_irA@mail.gmail.com>
 <CAG5Ck-6UTdSvN8Fz+F=4KjuTP6cNHHSj3FWE5b9XeGx8Gi7k=Q@mail.gmail.com>
 <A9E68172-D61E-4CB3-871A-4FB193DDD7C2@desy.de>
 <1464983821.1401.10.camel@mail.upb.de>
Message-ID: <CAG5Ck-55JVqB3DeeGDx4X0NJTN1jU9ah+pWhLeT46R5ZA+1Eig@mail.gmail.com>

--001a113dcfd8df1ce80534658def
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm pretty sure the patch was applied correctly.
0003-Linux-4.5-get_link-instead-of-follow_link-put_link.patch

tar -xvjf openafs-1.6.18-src.tar.bz2
cd openafs-1.6.18/
patch -p1 < ../0001-Linux-3.13-Check-return-value-from-bdi_init.patch
patching file src/afs/LINUX/osi_vfsops.c
patch -p1 < ../0002-Linux-4.5-no-highmem-in-symlink-ops.patch
patching file acinclude.m4
patching file src/afs/LINUX/osi_vnodeops.c
patch -p1 < ../0003-Linux-4.5-get_link-instead-of-follow_link-put_link.patc=
h
patching file acinclude.m4
patching file src/afs/LINUX/osi_vnodeops.c
patch -p1 < ../0005-Linux-4.5-don-t-access-i_mutex-directly.patch
patching file acinclude.m4
patching file src/afs/LINUX/osi_compat.h
patching file src/afs/LINUX/osi_vnodeops.c
./configure
--with-linux-kernel-headers=3D/usr/src/kernels/4.5.5-201.fc23.x86_64
make

same error message.

/home/gsgatlin/redhat/sources/openafs-1.6.18/src/libafs/MODLOAD-4.5.5-201.f=
c23.x86_64-MP/osi_vnodeops.c:1935:5:
error: implicit declaration of function =E2=80=98nd_set_link=E2=80=99
[-Werror=3Dimplicit-function-declaration]
     nd_set_link(nd, name);
     ^


patch contents:

https://paste.fedoraproject.org/374248/14649855/

Also, if there were concerns that I am a freeloader /  leech I did donate
some money to the openafs paypal.

Thanks,

On Fri, Jun 3, 2016 at 3:57 PM, Michael La=C3=9F <lass@mail.upb.de> wrote:

> Hi,
>
> Am Freitag, den 03.06.2016, 21:13 +0200 schrieb Stephan Wiesand:
> > On Jun 3, 2016, at 20:31 , Gary Gatling wrote:
> > > Thanks for any ideas anyone may have on how to compile openafs on 4.5
> > > kernel. I know its possible since Arch Linux pulled it off.
> >
> > Alas, if so, they haven't bothered submitting the magic patch to
> > gerrit.openafs.org. The changes under
> > https://gerrit.openafs.org/#/q/status:open+project:openafs+branch:mas
> > ter+topic:linux45 are all we have. I'll take your message as a report
> > that those changes are not sufficient to cope with Linux 4.5. It
> > makes me very sad.
>
> As I am maintaining the Arch Linux package: There is no magic patch,
> only the aforementioned patches are applied (gerrit 12264, 12265,
> 12268, 12274) and the kernel module compiles and works (as far as I can
> tell) with Linux 4.5.4.
>
> The first issue in the linked compile log is the following:
> >
> /home/gsgatlin/redhat/sources/openafs-1.6.18/src/libafs/MODLOAD-4.5.5-201=
.fc23.x86_64-MP/osi_vnodeops.c:
> In function =E2=80=98afs_linux_follow_link=E2=80=99:
> >
> /home/gsgatlin/redhat/sources/openafs-1.6.18/src/libafs/MODLOAD-4.5.5-201=
.fc23.x86_64-MP/osi_vnodeops.c:1935:5:
> error: implicit declaration of function =E2=80=98nd_set_link=E2=80=99
> [-Werror=3Dimplicit-function-declaration]
> >      nd_set_link(nd, name);
>
> This particular error occurs if 0003-Linux-4.5-get_link-instead-of-
> follow_link-put_link.patch (gerrit 12265) is not applied.
>
> Cheers,
> Michael
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>

--001a113dcfd8df1ce80534658def
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;m pretty sure the patch was applied correctly.<div><=
div>0003-Linux-4.5-get_link-instead-of-follow_link-put_link.patch</div></di=
v><div><br></div><div>tar -xvjf openafs-1.6.18-src.tar.bz2<br></div><div>cd=
 openafs-1.6.18/<br></div><div>patch -p1 &lt; ../0001-Linux-3.13-Check-retu=
rn-value-from-bdi_init.patch<br></div><div>patching file src/afs/LINUX/osi_=
vfsops.c<br></div><div><div>patch -p1 &lt; ../0002-Linux-4.5-no-highmem-in-=
symlink-ops.patch</div><div>patching file acinclude.m4</div><div>patching f=
ile src/afs/LINUX/osi_vnodeops.c</div></div><div><div>patch -p1 &lt; ../000=
3-Linux-4.5-get_link-instead-of-follow_link-put_link.patch</div><div>patchi=
ng file acinclude.m4</div><div>patching file src/afs/LINUX/osi_vnodeops.c</=
div></div><div><div>patch -p1 &lt; ../0005-Linux-4.5-don-t-access-i_mutex-d=
irectly.patch</div><div>patching file acinclude.m4</div><div>patching file =
src/afs/LINUX/osi_compat.h</div><div>patching file src/afs/LINUX/osi_vnodeo=
ps.c</div></div><div>./configure --with-linux-kernel-headers=3D/usr/src/ker=
nels/4.5.5-201.fc23.x86_64<br></div><div>make</div><div><br></div><div>same=
 error message.</div><div><br></div><div><div>/home/gsgatlin/redhat/sources=
/openafs-1.6.18/src/libafs/MODLOAD-4.5.5-201.fc23.x86_64-MP/osi_vnodeops.c:=
1935:5: error: implicit declaration of function =E2=80=98nd_set_link=E2=80=
=99 [-Werror=3Dimplicit-function-declaration]</div><div>=C2=A0 =C2=A0 =C2=
=A0nd_set_link(nd, name);</div><div>=C2=A0 =C2=A0 =C2=A0^</div></div><div><=
br></div><div><br></div><div>patch contents:</div><div><br></div><div><a hr=
ef=3D"https://paste.fedoraproject.org/374248/14649855/">https://paste.fedor=
aproject.org/374248/14649855/</a><br></div><div><br></div><div>Also, if the=
re were concerns that I am a freeloader / =C2=A0leech I did donate some mon=
ey to the openafs paypal.</div><div><br></div><div>Thanks,</div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jun 3, 2016 at=
 3:57 PM, Michael La=C3=9F <span dir=3D"ltr">&lt;<a href=3D"mailto:lass@mai=
l.upb.de" target=3D"_blank">lass@mail.upb.de</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">Hi,<br>
<span class=3D""><br>
Am Freitag, den 03.06.2016, 21:13 +0200 schrieb Stephan Wiesand:<br>
&gt; On Jun 3, 2016, at 20:31 , Gary Gatling wrote:<br>
</span><span class=3D"">&gt; &gt; Thanks for any ideas anyone may have on h=
ow to compile openafs on 4.5<br>
&gt; &gt; kernel. I know its possible since Arch Linux pulled it off.<br>
&gt;<br>
&gt; Alas, if so, they haven&#39;t bothered submitting the magic patch to<b=
r>
&gt; <a href=3D"http://gerrit.openafs.org" rel=3D"noreferrer" target=3D"_bl=
ank">gerrit.openafs.org</a>. The changes under<br>
&gt; <a href=3D"https://gerrit.openafs.org/#/q/status:open+project:openafs+=
branch:mas" rel=3D"noreferrer" target=3D"_blank">https://gerrit.openafs.org=
/#/q/status:open+project:openafs+branch:mas</a><br>
&gt; ter+topic:linux45 are all we have. I&#39;ll take your message as a rep=
ort<br>
&gt; that those changes are not sufficient to cope with Linux 4.5. It<br>
&gt; makes me very sad.<br>
<br>
</span>As I am maintaining the Arch Linux package: There is no magic patch,=
<br>
only the aforementioned patches are applied (gerrit 12264, 12265,<br>
12268, 12274) and the kernel module compiles and works (as far as I can<br>
tell) with Linux 4.5.4.<br>
<br>
The first issue in the linked compile log is the following:<br>
&gt; /home/gsgatlin/redhat/sources/openafs-1.6.18/src/libafs/MODLOAD-4.5.5-=
201.fc23.x86_64-MP/osi_vnodeops.c: In function =E2=80=98afs_linux_follow_li=
nk=E2=80=99:<br>
&gt; /home/gsgatlin/redhat/sources/openafs-1.6.18/src/libafs/MODLOAD-4.5.5-=
201.fc23.x86_64-MP/osi_vnodeops.c:1935:5: error: implicit declaration of fu=
nction =E2=80=98nd_set_link=E2=80=99 [-Werror=3Dimplicit-function-declarati=
on]<br>
&gt; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0nd_set_link(nd, name);<br>
<br>
This particular error occurs if 0003-Linux-4.5-get_link-instead-of-<br>
follow_link-put_link.patch (gerrit 12265) is not applied.<br>
<br>
Cheers,<br>
Michael<br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
OpenAFS-devel mailing list<br>
<a href=3D"mailto:OpenAFS-devel@openafs.org">OpenAFS-devel@openafs.org</a><=
br>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-devel" rel=3D=
"noreferrer" target=3D"_blank">https://lists.openafs.org/mailman/listinfo/o=
penafs-devel</a><br>
</div></div></blockquote></div><br></div>

--001a113dcfd8df1ce80534658def--

From lass@mail.upb.de  Fri Jun  3 21:34:30 2016
From: lass@mail.upb.de (Michael =?ISO-8859-1?Q?La=DF?=)
Date: Fri, 03 Jun 2016 22:34:30 +0200
Subject: [OpenAFS-devel] Re: having trouble compiling openafs kernel
 module in kernel 4.5
In-Reply-To: <CAG5Ck-55JVqB3DeeGDx4X0NJTN1jU9ah+pWhLeT46R5ZA+1Eig@mail.gmail.com>
References: <CAG5Ck-7X20pE5JhU+z8cxb7pTKhZ3A0KrHu1M+vnk2fDK-_irA@mail.gmail.com>
 <CAG5Ck-6UTdSvN8Fz+F=4KjuTP6cNHHSj3FWE5b9XeGx8Gi7k=Q@mail.gmail.com>
 <A9E68172-D61E-4CB3-871A-4FB193DDD7C2@desy.de>
 <1464983821.1401.10.camel@mail.upb.de>
 <CAG5Ck-55JVqB3DeeGDx4X0NJTN1jU9ah+pWhLeT46R5ZA+1Eig@mail.gmail.com>
Message-ID: <1464986070.1390.1.camel@mail.upb.de>

Am Freitag, den 03.06.2016, 16:27 -0400 schrieb Gary Gatling:
> I'm pretty sure the patch was applied correctly.
> 0003-Linux-4.5-get_link-instead-of-follow_link-put_link.patch
> 
> tar -xvjf openafs-1.6.18-src.tar.bz2
> cd openafs-1.6.18/
> patch -p1 < ../0001-Linux-3.13-Check-return-value-from-bdi_init.patch
> patching file src/afs/LINUX/osi_vfsops.c
> patch -p1 < ../0002-Linux-4.5-no-highmem-in-symlink-ops.patch
> patching file acinclude.m4
> patching file src/afs/LINUX/osi_vnodeops.c
> patch -p1 < ../0003-Linux-4.5-get_link-instead-of-follow_link-
> put_link.patch
> patching file acinclude.m4
> patching file src/afs/LINUX/osi_vnodeops.c
> patch -p1 < ../0005-Linux-4.5-don-t-access-i_mutex-directly.patch
> patching file acinclude.m4
> patching file src/afs/LINUX/osi_compat.h
> patching file src/afs/LINUX/osi_vnodeops.c
> ./configure --with-linux-kernel-headers=/usr/src/kernels/4.5.5-
> 201.fc23.x86_64
> make

There is one important step missing: After applying all the patches you
need to run "./regen.sh -q" which regenerates the configure script.

Cheers,
Michael

From gsgatlin@ncsu.edu  Fri Jun  3 22:21:23 2016
From: gsgatlin@ncsu.edu (Gary Gatling)
Date: Fri, 3 Jun 2016 17:21:23 -0400
Subject: [OpenAFS-devel] Re: having trouble compiling openafs kernel
 module in kernel 4.5
In-Reply-To: <1464986070.1390.1.camel@mail.upb.de>
References: <CAG5Ck-7X20pE5JhU+z8cxb7pTKhZ3A0KrHu1M+vnk2fDK-_irA@mail.gmail.com>
 <CAG5Ck-6UTdSvN8Fz+F=4KjuTP6cNHHSj3FWE5b9XeGx8Gi7k=Q@mail.gmail.com>
 <A9E68172-D61E-4CB3-871A-4FB193DDD7C2@desy.de>
 <1464983821.1401.10.camel@mail.upb.de>
 <CAG5Ck-55JVqB3DeeGDx4X0NJTN1jU9ah+pWhLeT46R5ZA+1Eig@mail.gmail.com>
 <1464986070.1390.1.camel@mail.upb.de>
Message-ID: <CAG5Ck-5rSo4ZZCLaqQ=YkOyYkYubt_UEFXtZB4ASkNW==8t3Vg@mail.gmail.com>

--001a113dcfd802e7b00534664e6e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Indeed. Thanks so much! That works. This gives me clues as to what I can do
to fix the rpm package I've been using. TIL. Have a great weekend.

On Fri, Jun 3, 2016 at 4:34 PM, Michael La=C3=9F <lass@mail.upb.de> wrote:

> Am Freitag, den 03.06.2016, 16:27 -0400 schrieb Gary Gatling:
> > I'm pretty sure the patch was applied correctly.
> > 0003-Linux-4.5-get_link-instead-of-follow_link-put_link.patch
> >
> > tar -xvjf openafs-1.6.18-src.tar.bz2
> > cd openafs-1.6.18/
> > patch -p1 < ../0001-Linux-3.13-Check-return-value-from-bdi_init.patch
> > patching file src/afs/LINUX/osi_vfsops.c
> > patch -p1 < ../0002-Linux-4.5-no-highmem-in-symlink-ops.patch
> > patching file acinclude.m4
> > patching file src/afs/LINUX/osi_vnodeops.c
> > patch -p1 < ../0003-Linux-4.5-get_link-instead-of-follow_link-
> > put_link.patch
> > patching file acinclude.m4
> > patching file src/afs/LINUX/osi_vnodeops.c
> > patch -p1 < ../0005-Linux-4.5-don-t-access-i_mutex-directly.patch
> > patching file acinclude.m4
> > patching file src/afs/LINUX/osi_compat.h
> > patching file src/afs/LINUX/osi_vnodeops.c
> > ./configure --with-linux-kernel-headers=3D/usr/src/kernels/4.5.5-
> > 201.fc23.x86_64
> > make
>
> There is one important step missing: After applying all the patches you
> need to run "./regen.sh -q" which regenerates the configure script.
>
> Cheers,
> Michael
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>

--001a113dcfd802e7b00534664e6e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Indeed. Thanks so much! That works. This gives me clues as=
 to what I can do to fix the rpm package I&#39;ve been using. TIL. Have a g=
reat weekend.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Fri, Jun 3, 2016 at 4:34 PM, Michael La=C3=9F <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:lass@mail.upb.de" target=3D"_blank">lass@mail.upb.de</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">Am Freit=
ag, den 03.06.2016, 16:27 -0400 schrieb Gary Gatling:<br>
&gt; I&#39;m pretty sure the patch was applied correctly.<br>
&gt; 0003-Linux-4.5-get_link-instead-of-follow_link-put_link.patch<br>
&gt;<br>
&gt; tar -xvjf openafs-1.6.18-src.tar.bz2<br>
&gt; cd openafs-1.6.18/<br>
&gt; patch -p1 &lt; ../0001-Linux-3.13-Check-return-value-from-bdi_init.pat=
ch<br>
&gt; patching file src/afs/LINUX/osi_vfsops.c<br>
&gt; patch -p1 &lt; ../0002-Linux-4.5-no-highmem-in-symlink-ops.patch<br>
&gt; patching file acinclude.m4<br>
&gt; patching file src/afs/LINUX/osi_vnodeops.c<br>
&gt; patch -p1 &lt; ../0003-Linux-4.5-get_link-instead-of-follow_link-<br>
&gt; put_link.patch<br>
&gt; patching file acinclude.m4<br>
&gt; patching file src/afs/LINUX/osi_vnodeops.c<br>
&gt; patch -p1 &lt; ../0005-Linux-4.5-don-t-access-i_mutex-directly.patch<b=
r>
&gt; patching file acinclude.m4<br>
&gt; patching file src/afs/LINUX/osi_compat.h<br>
&gt; patching file src/afs/LINUX/osi_vnodeops.c<br>
&gt; ./configure --with-linux-kernel-headers=3D/usr/src/kernels/4.5.5-<br>
&gt; 201.fc23.x86_64<br>
&gt; make<br>
<br>
</span>There is one important step missing: After applying all the patches =
you<br>
need to run &quot;./regen.sh -q&quot; which regenerates the configure scrip=
t.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Cheers,<br>
Michael<br>
_______________________________________________<br>
OpenAFS-devel mailing list<br>
<a href=3D"mailto:OpenAFS-devel@openafs.org">OpenAFS-devel@openafs.org</a><=
br>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-devel" rel=3D=
"noreferrer" target=3D"_blank">https://lists.openafs.org/mailman/listinfo/o=
penafs-devel</a><br>
</div></div></blockquote></div><br></div>

--001a113dcfd802e7b00534664e6e--

From deywos@mit.edu  Wed Jun  8 01:56:37 2016
From: deywos@mit.edu (Deven Lahoti)
Date: Tue, 7 Jun 2016 20:56:37 -0400
Subject: [OpenAFS-devel] OpenAFS and grsecurity
Message-ID: <CANGLR7s3wzpQuXqUdOc7-ZGCkSbY2EDPT=TB=zAupx8B_Pjp3A@mail.gmail.com>

--94eb2c1231e477ee7b0534b9c95e
Content-Type: text/plain; charset=UTF-8

I patched OpenAFS to work on Gentoo Hardened 4.4.8-r1; it just required a
few changes in struct initializations to work with struct randomization.
Looking at old messages on the list, the reason these weren't changed
before was for compatibility with old compilers, but there are other struct
initializations in the codebase now that use designated initizalizers, so
it shouldn't be a problem. Additionally, the config options listed at the
end failed to be detected by configure, but I'm not sure why. I don't
really know how to use autoconf, so I had to hardcode them, which is
acceptable for my use but clearly not in the actual codebase. I'm hoping
someone can help me figure this out so it will build normally.

Here's the patch for the structs:
http://web.mit.edu/deywos/www/structs.patch

Here are the config options:
NEW_EXPORT_OPS EXPORT_OP_ENCODE_FH_TAKES_INODES
STRUCT_FILE_OPERATIONS_HAS_READ_ITER STRUCT_KEY_TYPE_HAS_MATCH_PREPARSE
STRUCT_SUPER_OPERATIONS_HAS_ALLOC_INODE
STRUCT_SUPER_OPERATIONS_HAS_EVICT_INODE STRUCT_KEY_TYPE_HAS_PREPARSE
STRUCT_FILE_OPERATIONS_HAS_ITERATE DOP_REVALIDATE_TAKES_UNSIGNED
HAVE_LINUX_INODE_OPERATIONS_FOLLOW_LINK_NO_NAMEIDATA
STRUCT_DENTRY_OPERATIONS_HAS_D_AUTOMOUNT
STRUCT_ADDRESS_SPACE_OPERATIONS_HAS_WRITE_BEGIN IOP_LOOKUP_TAKES_UNSIGNED
IOP_MKDIR_TAKES_UMODE_T
HAVE_LINUX_INODE_OPERATIONS_FOLLOW_LINK_NO_NAMEIDATA
HAVE_LINUX_INODE_OPERATIONS_PUT_LINK_NO_NAMEIDATA
AOP_WRITEPAGE_TAKES_WRITEBACK_CONTROL DOP_D_DELETE_TAKES_CONST

Thanks,
Deven

--94eb2c1231e477ee7b0534b9c95e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I patched OpenAFS to work on Gentoo Hardened 4.4.8-r1; it =
just required a few changes in struct initializations to work with struct r=
andomization. Looking at old messages on the list, the reason these weren&#=
39;t changed before was for compatibility with old compilers, but there are=
 other struct initializations in the codebase now that use designated initi=
zalizers, so it shouldn&#39;t be a problem. Additionally, the config option=
s listed at the end failed to be detected by configure, but I&#39;m not sur=
e why. I don&#39;t really know how to use autoconf, so I had to hardcode th=
em, which is acceptable for my use but clearly not in the actual codebase. =
I&#39;m hoping someone can help me figure this out so it will build normall=
y.<br><br>Here&#39;s the patch for the structs: <a href=3D"http://web.mit.e=
du/deywos/www/structs.patch">http://web.mit.edu/deywos/www/structs.patch</a=
><br><div><br>Here are the config options:<br>NEW_EXPORT_OPS
EXPORT_OP_ENCODE_FH_TAKES_INODES
STRUCT_FILE_OPERATIONS_HAS_READ_ITER
STRUCT_KEY_TYPE_HAS_MATCH_PREPARSE
STRUCT_SUPER_OPERATIONS_HAS_ALLOC_INODE
STRUCT_SUPER_OPERATIONS_HAS_EVICT_INODE
STRUCT_KEY_TYPE_HAS_PREPARSE
STRUCT_FILE_OPERATIONS_HAS_ITERATE
DOP_REVALIDATE_TAKES_UNSIGNED
HAVE_LINUX_INODE_OPERATIONS_FOLLOW_LINK_NO_NAMEIDATA
STRUCT_DENTRY_OPERATIONS_HAS_D_AUTOMOUNT
STRUCT_ADDRESS_SPACE_OPERATIONS_HAS_WRITE_BEGIN
IOP_LOOKUP_TAKES_UNSIGNED
IOP_MKDIR_TAKES_UMODE_T
HAVE_LINUX_INODE_OPERATIONS_FOLLOW_LINK_NO_NAMEIDATA
HAVE_LINUX_INODE_OPERATIONS_PUT_LINK_NO_NAMEIDATA
AOP_WRITEPAGE_TAKES_WRITEBACK_CONTROL
DOP_D_DELETE_TAKES_CONST<br><br></div><div>Thanks,<br></div><div>Deven<br><=
/div></div>

--94eb2c1231e477ee7b0534b9c95e--

From jaltman@auristor.com  Wed Jun  8 04:01:00 2016
From: jaltman@auristor.com (Jeffrey Altman)
Date: Tue, 7 Jun 2016 23:01:00 -0400
Subject: [OpenAFS-devel] OpenAFS and grsecurity
In-Reply-To: <CANGLR7s3wzpQuXqUdOc7-ZGCkSbY2EDPT=TB=zAupx8B_Pjp3A@mail.gmail.com>
References: <CANGLR7s3wzpQuXqUdOc7-ZGCkSbY2EDPT=TB=zAupx8B_Pjp3A@mail.gmail.com>
Message-ID: <0fdcf908-0061-6607-400c-6c6356084b95@auristor.com>

This is a cryptographically signed message in MIME format.

--------------ms010104010902060205020202
Content-Type: multipart/mixed;
 boundary="------------F9326D28543A92B4726E2FBB"

This is a multi-part message in MIME format.
--------------F9326D28543A92B4726E2FBB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/7/2016 8:56 PM, Deven Lahoti wrote:
> I patched OpenAFS to work on Gentoo Hardened 4.4.8-r1; it just required=

> a few changes in struct initializations to work with struct
> randomization. Looking at old messages on the list, the reason these
> weren't changed before was for compatibility with old compilers,

Its not just for "old compilers" but for platforms that do not have full
C99 support such as Windows.  OpenAFS still builds on many platforms and
OS revisions that do not have the necessary support.

It is almost certainly ok to use labeled structure initialization in
platform specific code which is not compiled on all platforms.  In your
changes those to

  src/afs/LINUX/osi_misc.c
  src/afs/LINUX/osi_sysctl.c

since those are platform specific.   It is quite possible that it is ok
for most current versions of UNIX and so

  src/afs/afs_fetchstore.c

is possibly fine.  However, src/rxkad/rxkad_client.c is cross-platform
and is certainly built on platforms without the necessary support.

That isn't to say that you cannot add a patch to change how
initialization is performed but that it would have to be conditional
upon whether or not the compiler has the necessary language support.

Jeffrey Altman





--------------F9326D28543A92B4726E2FBB
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:AuriStor, Inc.
adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St=
ates
email;internet:jaltman@auristor.com
title:Founder and CEO
tel;work:+1-212-769-9018
note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=
=3D0D=3D0A=3D
	Skype: jeffrey.e.altman=3D0D=3D0A=3D
=09
url:https://www.auristor.com/
version:2.1
end:vcard


--------------F9326D28543A92B4726E2FBB--

--------------ms010104010902060205020202
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DEkwggYFMIIE7aADAgECAhAxSdDYnMC0s7K+ddH7ywANMA0GCSqGSIb3DQEBCwUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5
bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3
MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH
NTAeFw0xNTExMDEwMDAwMDBaFw0xNjExMDEyMzU5NTlaMIGnMS4wLAYDVQQDDCVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQgLSAxNDQ2NDA0MDI1NjI1MSMwIQYJKoZIhvcNAQkBFhRqYWx0bWFu
QGF1cmlzdG9yLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYDVQQLDBVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdvcmswggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC2cv6bENZULsb1FNyEBI47G2kA7Rogocg5u0qnQuDMCCNH
DnXkI62H2z/464AS8AGp4FcZIdvCPYp0POFlOl2XEiyA59FEDi+s3b33nLrnVOa4esw2NFBi
ZvwHvniUjgwWSUcS5V5+VhXeIKBL1U1NtMtB2XEVnc72RiQZB3KqzlS9GUvtSTdmCc6ULD/t
P009yCsBqY6NR/nug5NtUja2N+xUC2l8coYU1ingj/M4+fT8KcSq5t8laj0E+3X9ZPYlN9in
L364hXB1b+EHfxp0F0wZdsCapkEKV2VN16S1Ee5rccJIMaAJxrybK7NdI36Es/XqWlQzSeVN
wUYdwejrAgMBAAGjggIqMIICJjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAgBgNV
HSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFInhroYG7TrlBeOJmwRc
a0rfA3jtMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMGwGA1UdIARlMGMwYQYL
YIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMw
KAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwXQYDVR0fBFYwVDBS
oFCgToZMaHR0cDovL3BraS1jcmwuc3ltYXV0aC5jb20vY2FfNTdkZTdhMjM4ZDQ1ZDhkNGZj
NzFmOGE1YzZiODFjOTMvTGF0ZXN0Q1JMLmNybDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUH
MAKGMmh0dHA6Ly9jYWNlci5zeW1hdXRoLmNvbS9tcGtpL3N5bWNjMWluZHN1YmNhZzUuY3J0
MB8GA1UdIwQYMBaAFGcZtj2lebszYNgtU9OMCT0HrBhwMCsGCmCGSAGG+EUBEAMEHTAbBhJg
hkgBhvhFARABAgIEAa3ukhMWBTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hN
Nkx5OXdhMmt0Y21FdWMzbHRZWFYwYUM1amIyMD0wDQYJKoZIhvcNAQELBQADggEBAHhpoe3z
j0uxbWFz4Q7F2KyRJTgREbQ+imVv3ibbd2uvnckJ+vTNJuFoaORXKTt3B8TUT8rBTwXm35D5
K4DOrKMVS0iyR9PDobLpjQM8FcIGUdbGWeZZq/1zoWhi3RtFNzZaSKXjwiQUUWYTZUE7rUmj
qu7fiACksPAAdyG12FJtk1pdVByqmaFC75/z2Qs/jVjyySpy2SRg8wlpqM2h8tl9SGska/BT
gXLHJMhKrHQvBi+9Xo3MrmJA5Z3f5vcheoOAoM5/ScHBUXWDG0+NnEIb340By0adU823pF9c
K4gxI0ZJNID+eaT0XCqg47QFOZYZUlm3s4rDi1l1iPIHekwwggY8MIIFJKADAgECAhAHAqIa
hbhLZZ4YCm7m9aNlMA0GCSqGSIb3DQEBCwUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO
VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNV
BAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx
RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkgLSBHMzAeFw0xNTEwMDEwMDAwMDBaFw0yNTA5MzAyMzU5NTlaMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5
bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3
MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH
NTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANb7DTFJIsAMuu9OLRe4tDDlNNKs
Ce7JiQBd9K4TEbMTjlXPIhioIAam/SXLaJS0oIKQDm6WkkTuFbm07PrPeT1p1Jwf3CCaDijV
DbXGnjrx1GUZwIQzTY7aivHWJ7kDoNH6KJyCk2z3DYV9W+lOmWL+k0LS7j6zcVeGl0bL3w3h
xoRasw2P9fQQigVdn2hG7AiwWEKC9r4tEEamJAsn/pgUU4OTgtvqwD9PolhhtUtyaRJfM1n2
+bNMAGTOhcWGkgxuHOsoz3GpkKl0mXQk60jhDl1oEqgBZujumrIv+D3Nt3gkzqVgfOgWPUnx
B7ozvjIrwmejFsdvwNJalATCa0UCAwEAAaOCAj4wggI6MDcGCCsGAQUFBwEBBCswKTAnBggr
BgEFBQcwAYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMBIGA1UdEwEB/wQIMAYBAf8C
AQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3
LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t
L3JwYTAvBgNVHR8EKDAmMCSgIqAghh5odHRwOi8vcy5zeW1jYi5jb20vcGNhMS1nMy5jcmww
DgYDVR0PAQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0y
LTIxNzAdBgNVHQ4EFgQUZxm2PaV5uzNg2C1T04wJPQesGHAwgfEGA1UdIwSB6TCB5qGB0KSB
zTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5j
LiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAx
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSF
CwDPrzhIzrGkMA0GCSqGSIb3DQEBCwUAA4IBAQBGGeQndTu+r+LaohRgjx5EkIFpK2NJNY3p
drqfmI8TgdfL/GUb+A5j3pQodPvjb9jJKnoOVKaDrilK9itR/T04ErvdY0X7ZMw+VIZ/TkJt
I7cdC/36zA2OkzXK5UX5zy9/eT1jGMdHI0r2qRQArX5ZVRqJJ9uUoJE4xv5AlaNg9l24yMUW
7ZxmaRRGEErKcCpv0VDgJhrTUrRHcotF0r0DuaXc2QjzkKt0cKvKoE7wwE7k4L5PkBFgJwwr
HN/nbMp1tCXnkUiqkrRRdV8pm0cXHL3J6s91rXUjz/LF31qrt2vKu7heq9WjcNRo8xd6mwug
FDz76IFWaOjPXXxzuC68MYIEYjCCBF4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQK
ExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y
azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1AhAxSdDYnMC0s7K+ddH7ywAN
MA0GCWCGSAFlAwQCAQUAoIICdzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0xNjA2MDgwMzAxMDBaMC8GCSqGSIb3DQEJBDEiBCBGFy6vZlErfVzjP7RPJAuT
Cie3NlD4Ld8dcS+YEKQ/GDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB
ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVT
MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1
c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1AhAxSdDYnMC0
s7K+ddH7ywANMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV
BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3
b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj
IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzUCEDFJ0NicwLSzsr510fvL
AA0wDQYJKoZIhvcNAQEBBQAEggEAVJwUQO4RsN39wWcu2+xCxWu6so2belt57FxM8hmjhB3s
y4tnpgfu/uw+lZcTmrWspI5W+FQhVJeT19KiOGTdoS00AaM6aQZUDI0RYN50e947C6fEHQ+N
EvNz34k8AU5oYpvMpU67ZK7/a5RbKAf1erOSmhp7yKzw9hUEYdDMhZvXtwRsqH42PAWXOB7D
XtiDn+nmTVu43ideWGU6/0412RsSfIoFyyHw0Ut95atwNiwZB+FplDHGmburXEyb4iDKrX+u
jIHQXVni7IVEO5OSgYlsUPuMW5kLmNUVw9vGhk8Dmx3hVdQxGU6TbfibpZOZ1xaBvmfTDTJg
zBN0bANwtgAAAAAAAA==
--------------ms010104010902060205020202--


From deywos@mit.edu  Thu Jun  9 02:40:13 2016
From: deywos@mit.edu (Deven Lahoti)
Date: Wed, 8 Jun 2016 21:40:13 -0400
Subject: [OpenAFS-devel] OpenAFS and grsecurity
In-Reply-To: <0fdcf908-0061-6607-400c-6c6356084b95@auristor.com>
References: <CANGLR7s3wzpQuXqUdOc7-ZGCkSbY2EDPT=TB=zAupx8B_Pjp3A@mail.gmail.com>
 <0fdcf908-0061-6607-400c-6c6356084b95@auristor.com>
Message-ID: <CANGLR7s8tAw-Qqyzkf7CmiG_-b3su6vEf3Z5xLKfr8bGr4=0JQ@mail.gmail.com>

--001a114e24823177c80534ce8366
Content-Type: text/plain; charset=UTF-8

So an

#if __STDC_VERSION__ >= 199901L

should be sufficient then? Any advice on fixing the config option detection?

Deven

--001a114e24823177c80534ce8366
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><div><div><div>So an<br><br></div>#if __STDC_VERSION__ &gt;= 199901L<br><br></div>should be sufficient then? Any advice on fixing the config option detection?<br><br></div>Deven<br></div>

--001a114e24823177c80534ce8366--

From jaltman@auristor.com  Sun Jun 12 15:44:52 2016
From: jaltman@auristor.com (Jeffrey Altman)
Date: Sun, 12 Jun 2016 10:44:52 -0400
Subject: [OpenAFS-devel] Approval function against spam for mailing list
 and issue tracker
In-Reply-To: <575D5AE8.3030002@richtercloud.de>
References: <5749ADB6.2070607@richtercloud.de>
 <158827f0-bbd9-ebc2-b26f-9be72e73dbb8@auristor.com>
 <574ABE21.30103@richtercloud.de> <575D5AE8.3030002@richtercloud.de>
Message-ID: <370d0950-bb50-f49c-5bc6-19ea44083c3c@auristor.com>

This is a cryptographically signed message in MIME format.

--------------ms010307060207090302020803
Content-Type: multipart/mixed;
 boundary="------------2784CA2D14EC4FA7BB3F7F13"

This is a multi-part message in MIME format.
--------------2784CA2D14EC4FA7BB3F7F13
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/12/2016 8:51 AM, Karl-Philipp Richter wrote:
> Am 29.05.2016 um 12:02 schrieb Karl-Philipp Richter:
>> There were 3 or 4 spam reports in the issue tracker (between 133097 an=
d
>> http://rt.central.org/rt/Ticket/Display.html?id=3D133085). They must h=
ave
>> been deleted. So, if you as admins don't mind the issue tracker spam
>> fighting seems to work fine.
> A screenshot of 14 of top 16 issues being (suspected based on title)
> spam attached. It starts to be slightly annoying to search issues by
> date, e.g. latest issues.
>=20
> -Kalle
>=20

As I have said previously, there is no perfect spam filter.  If there
was, there would be no spam in the world.  I don't know if you run a
mail service or not but as someone who has, the choices are simple.

 1. be too aggressive when filtering in which case non-spam is marked
    as spam.  For RT that would mean that non-spam submissions do not
    make it into the appropriate RT queue.

 2. be less aggressive when filtering in which case a human has to
    manually delete the spam.  For RT that means that an authorized
    human must review the RT queues and delete the spam.

The total number of spam tickets created in a two week period was 22
across all of the queues.  That is an exceedingly low number compared to
the actual number of spam messages sent to openafs-* mailing lists.  The
spam filters are doing a very good job.

While I appreciate that you are annoyed by the periodic and temporary
existence of spam within the public OpenAFS RT queues I want to make
something very clear.  The mail servers and the OpenAFS RT queues are
provided by volunteers, paid for and administered out of the goodness
of their hearts.  No one is paying for a commercial spam filtering
service and to the best of my knowledge no one is paying for the use of
commercial DNS black lists.  Only the free DNS black lists are used
which are much less effective and blocking spammers.

The OpenAFS RT queues are administered by volunteers.  No one is paid to
monitor OpenAFS RT for spam.  No one is paid to respond to OpenAFS RT
submissions.

Speaking for myself and only myself, I don't look at RT all that often
unless I am responding to a non-spam report or working on an open
ticket.  I receive an e-mail notification of every new ticket that is
created.  Seeing a spam notification doesn't cause me to drop what I'm
doing, go to RT and delete it.  On the other hand, receiving a
notification of an actual bug does often result in my logging into RT to
see the details of the report.  While I am logged into RT I will delete
spam messages from all of the queues to which I have access.  If the
number of actual bugs reported is low, the frequency at which I delete
spam will be low as well.

In response to your non-spam e-mail I have removed all spam messages
from OpenAFS RT.

Jeffrey Altman


--------------2784CA2D14EC4FA7BB3F7F13
Content-Type: text/x-vcard; charset=utf-8;
 name="jaltman.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="jaltman.vcf"

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:AuriStor, Inc.
adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United St=
ates
email;internet:jaltman@auristor.com
title:Founder and CEO
tel;work:+1-212-769-9018
note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=
=3D0D=3D0A=3D
	Skype: jeffrey.e.altman=3D0D=3D0A=3D
=09
url:https://www.auristor.com/
version:2.1
end:vcard


--------------2784CA2D14EC4FA7BB3F7F13--

--------------ms010307060207090302020803
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DEkwggYFMIIE7aADAgECAhAxSdDYnMC0s7K+ddH7ywANMA0GCSqGSIb3DQEBCwUAMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5
bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3
MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH
NTAeFw0xNTExMDEwMDAwMDBaFw0xNjExMDEyMzU5NTlaMIGnMS4wLAYDVQQDDCVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQgLSAxNDQ2NDA0MDI1NjI1MSMwIQYJKoZIhvcNAQkBFhRqYWx0bWFu
QGF1cmlzdG9yLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYDVQQLDBVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdvcmswggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC2cv6bENZULsb1FNyEBI47G2kA7Rogocg5u0qnQuDMCCNH
DnXkI62H2z/464AS8AGp4FcZIdvCPYp0POFlOl2XEiyA59FEDi+s3b33nLrnVOa4esw2NFBi
ZvwHvniUjgwWSUcS5V5+VhXeIKBL1U1NtMtB2XEVnc72RiQZB3KqzlS9GUvtSTdmCc6ULD/t
P009yCsBqY6NR/nug5NtUja2N+xUC2l8coYU1ingj/M4+fT8KcSq5t8laj0E+3X9ZPYlN9in
L364hXB1b+EHfxp0F0wZdsCapkEKV2VN16S1Ee5rccJIMaAJxrybK7NdI36Es/XqWlQzSeVN
wUYdwejrAgMBAAGjggIqMIICJjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAgBgNV
HSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFInhroYG7TrlBeOJmwRc
a0rfA3jtMB8GA1UdEQQYMBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMGwGA1UdIARlMGMwYQYL
YIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMw
KAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwXQYDVR0fBFYwVDBS
oFCgToZMaHR0cDovL3BraS1jcmwuc3ltYXV0aC5jb20vY2FfNTdkZTdhMjM4ZDQ1ZDhkNGZj
NzFmOGE1YzZiODFjOTMvTGF0ZXN0Q1JMLmNybDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUH
MAKGMmh0dHA6Ly9jYWNlci5zeW1hdXRoLmNvbS9tcGtpL3N5bWNjMWluZHN1YmNhZzUuY3J0
MB8GA1UdIwQYMBaAFGcZtj2lebszYNgtU9OMCT0HrBhwMCsGCmCGSAGG+EUBEAMEHTAbBhJg
hkgBhvhFARABAgIEAa3ukhMWBTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hN
Nkx5OXdhMmt0Y21FdWMzbHRZWFYwYUM1amIyMD0wDQYJKoZIhvcNAQELBQADggEBAHhpoe3z
j0uxbWFz4Q7F2KyRJTgREbQ+imVv3ibbd2uvnckJ+vTNJuFoaORXKTt3B8TUT8rBTwXm35D5
K4DOrKMVS0iyR9PDobLpjQM8FcIGUdbGWeZZq/1zoWhi3RtFNzZaSKXjwiQUUWYTZUE7rUmj
qu7fiACksPAAdyG12FJtk1pdVByqmaFC75/z2Qs/jVjyySpy2SRg8wlpqM2h8tl9SGska/BT
gXLHJMhKrHQvBi+9Xo3MrmJA5Z3f5vcheoOAoM5/ScHBUXWDG0+NnEIb340By0adU823pF9c
K4gxI0ZJNID+eaT0XCqg47QFOZYZUlm3s4rDi1l1iPIHekwwggY8MIIFJKADAgECAhAHAqIa
hbhLZZ4YCm7m9aNlMA0GCSqGSIb3DQEBCwUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO
VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNV
BAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx
RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkgLSBHMzAeFw0xNTEwMDEwMDAwMDBaFw0yNTA5MzAyMzU5NTlaMIGmMQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5
bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3
MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH
NTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANb7DTFJIsAMuu9OLRe4tDDlNNKs
Ce7JiQBd9K4TEbMTjlXPIhioIAam/SXLaJS0oIKQDm6WkkTuFbm07PrPeT1p1Jwf3CCaDijV
DbXGnjrx1GUZwIQzTY7aivHWJ7kDoNH6KJyCk2z3DYV9W+lOmWL+k0LS7j6zcVeGl0bL3w3h
xoRasw2P9fQQigVdn2hG7AiwWEKC9r4tEEamJAsn/pgUU4OTgtvqwD9PolhhtUtyaRJfM1n2
+bNMAGTOhcWGkgxuHOsoz3GpkKl0mXQk60jhDl1oEqgBZujumrIv+D3Nt3gkzqVgfOgWPUnx
B7ozvjIrwmejFsdvwNJalATCa0UCAwEAAaOCAj4wggI6MDcGCCsGAQUFBwEBBCswKTAnBggr
BgEFBQcwAYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMBIGA1UdEwEB/wQIMAYBAf8C
AQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3
LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t
L3JwYTAvBgNVHR8EKDAmMCSgIqAghh5odHRwOi8vcy5zeW1jYi5jb20vcGNhMS1nMy5jcmww
DgYDVR0PAQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0y
LTIxNzAdBgNVHQ4EFgQUZxm2PaV5uzNg2C1T04wJPQesGHAwgfEGA1UdIwSB6TCB5qGB0KSB
zTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5j
LiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAx
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSF
CwDPrzhIzrGkMA0GCSqGSIb3DQEBCwUAA4IBAQBGGeQndTu+r+LaohRgjx5EkIFpK2NJNY3p
drqfmI8TgdfL/GUb+A5j3pQodPvjb9jJKnoOVKaDrilK9itR/T04ErvdY0X7ZMw+VIZ/TkJt
I7cdC/36zA2OkzXK5UX5zy9/eT1jGMdHI0r2qRQArX5ZVRqJJ9uUoJE4xv5AlaNg9l24yMUW
7ZxmaRRGEErKcCpv0VDgJhrTUrRHcotF0r0DuaXc2QjzkKt0cKvKoE7wwE7k4L5PkBFgJwwr
HN/nbMp1tCXnkUiqkrRRdV8pm0cXHL3J6s91rXUjz/LF31qrt2vKu7heq9WjcNRo8xd6mwug
FDz76IFWaOjPXXxzuC68MYIEYjCCBF4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQK
ExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y
azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBD
bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1AhAxSdDYnMC0s7K+ddH7ywAN
MA0GCWCGSAFlAwQCAQUAoIICdzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0xNjA2MTIxNDQ0NTJaMC8GCSqGSIb3DQEJBDEiBCAe78Jl1h/eh0vq+nVj4dAY
9NbXjs0mGrbuUp0BnNzHFDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB
ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMIHMBgkrBgEEAYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVT
MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1
c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5T
eW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1AhAxSdDYnMC0
s7K+ddH7ywANMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV
BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3
b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj
IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzUCEDFJ0NicwLSzsr510fvL
AA0wDQYJKoZIhvcNAQEBBQAEggEAkTel7XXNmpeF9pXIg+4r2i3LdowF3IpvPIh6GEBTG6H4
8FzJDgpqP9SQ0R8T/aVAm0VPJPCwNGPC6dJXSMN8X+IsIav2rJkOI4+eaBe5pt8Ndzok1MYF
MvylWR+GYGQQbIfjLP7fU57ejzBwtlaRQi9fDokswqYzunDOg+/ZaC58fZCUfV8Jpu8AjKNE
cpbWFwWNjniR6Cqg1NfVVadVSuDdh5nIjgPInotl52XBRgIkP+A0dfslb0saxesAZtS4mwAB
+kPmDr7ohanjaDstCZYQC086kAwlFfUYy6+KYGI83N9WzJXyWumE2nyz3GWk/nhlmyTnQ9f+
EZ1AMpFrfAAAAAAAAA==
--------------ms010307060207090302020803--


From stephan.wiesand@desy.de  Thu Jun 16 16:55:36 2016
From: stephan.wiesand@desy.de (Stephan Wiesand)
Date: Thu, 16 Jun 2016 17:55:36 +0200
Subject: [OpenAFS-devel] linux45: smoke test failed
Message-ID: <201647C0-EA11-4017-AF19-342BDAEFBD27@desy.de>

I smoke tested what was planned to be OpenAFS 1.6.18.1, as discussed in =
yesterday's release team meeting, on a Fedora 23 x86_64 VM with kernel =
4.5.6-200 today. The result was disappointing:

git clone git://gerrit.openafs.org/openafs.git
cd openafs
git log=20
# scrolled through a few dozen changes, took a couple of seconds
git checkout openafs-stable-1_6_18

At this point I got the following error:

fatal: Unable to read current working directory: No such file or =
directory

A "cd; cd -" cures this for a while, and there's no apparent data =
corruption. I'm still worried. The problem isn't 100% reproducible, but =
it doesn't take too may tries checking out random tags or branches.

This was plain 1.6.18 + gerrit 12300 12301 12302 12274.

Cache is on ext4, no separate partition, default size as set by our RPM =
(I think 100MB, but I don't have access to the VM right now to check).

The small cache size may contribute to the problem. But I found no =
errors logged anywhere, and this shouldn't happen no matter how small =
the cache is.


NB we have a user report of exactly this problem happening frequently =
while just editing files in a local git repo in AFS space. The data is a =
bit sketchy, but it's probably Ubuntu 14.04 with its current default =
kernel and the openafs packages from Anders' ppa. I'll try to get us =
more data.


Any thoughts? For the time being I'm considering this a showstopper for =
1.6.18.1, and it looks like we're not quite there yet regarding Linux =
4.5, let alone 4.6 or the 4.7 due in a few weeks :-(

--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany


From kaduk@MIT.EDU  Fri Jun 17 03:45:26 2016
From: kaduk@MIT.EDU (Benjamin Kaduk)
Date: Thu, 16 Jun 2016 22:45:26 -0400 (EDT)
Subject: [OpenAFS-devel] linux45: smoke test failed
In-Reply-To: <201647C0-EA11-4017-AF19-342BDAEFBD27@desy.de>
References: <201647C0-EA11-4017-AF19-342BDAEFBD27@desy.de>
Message-ID: <alpine.GSO.1.10.1606162244020.18480@multics.mit.edu>

On Thu, 16 Jun 2016, Stephan Wiesand wrote:

> I smoke tested what was planned to be OpenAFS 1.6.18.1, as discussed in yesterday's release team meeting, on a Fedora 23 x86_64 VM with kernel 4.5.6-200 today. The result was disappointing:
>
> git clone git://gerrit.openafs.org/openafs.git

Is the pwd the root of a volume?

> cd openafs
> git log
> # scrolled through a few dozen changes, took a couple of seconds
> git checkout openafs-stable-1_6_18
>
> At this point I got the following error:
>
> fatal: Unable to read current working directory: No such file or directory
>
> A "cd; cd -" cures this for a while, and there's no apparent data corruption. I'm still worried. The problem isn't 100% reproducible, but it doesn't take too may tries checking out random tags or branches.
>
> This was plain 1.6.18 + gerrit 12300 12301 12302 12274.
>
> Cache is on ext4, no separate partition, default size as set by our RPM (I think 100MB, but I don't have access to the VM right now to check).
>
> The small cache size may contribute to the problem. But I found no errors logged anywhere, and this shouldn't happen no matter how small the cache is.

Please check if the cmdebug output is empty (I expect it is, but it is
good to check).

> NB we have a user report of exactly this problem happening frequently while just editing files in a local git repo in AFS space. The data is a bit sketchy, but it's probably Ubuntu 14.04 with its current default kernel and the openafs packages from Anders' ppa. I'll try to get us more data.
>
>
> Any thoughts? For the time being I'm considering this a showstopper for
> 1.6.18.1, and it looks like we're not quite there yet regarding Linux
> 4.5, let alone 4.6 or the 4.7 due in a few weeks :-(

Can you run the same test on a 4.4 kernel for comparison?

Thanks,

Ben

From stephan.wiesand@desy.de  Fri Jun 17 16:30:28 2016
From: stephan.wiesand@desy.de (Stephan Wiesand)
Date: Fri, 17 Jun 2016 17:30:28 +0200
Subject: [OpenAFS-devel] linux45: smoke test failed
In-Reply-To: <alpine.GSO.1.10.1606162244020.18480@multics.mit.edu>
References: <201647C0-EA11-4017-AF19-342BDAEFBD27@desy.de> <alpine.GSO.1.10.1606162244020.18480@multics.mit.edu>
Message-ID: <52B7EDC0-169C-4061-9DAB-F8656C6DB40C@desy.de>

On Jun 17, 2016, at 04:45 , Benjamin Kaduk wrote:

> On Thu, 16 Jun 2016, Stephan Wiesand wrote:
>=20
>> I smoke tested what was planned to be OpenAFS 1.6.18.1, as discussed =
in yesterday's release team meeting, on a Fedora 23 x86_64 VM with =
kernel 4.5.6-200 today. The result was disappointing:
>>=20
>> git clone git://gerrit.openafs.org/openafs.git
>=20
> Is the pwd the root of a volume?

No, everything happens at least one level below.

>> cd openafs
>> git log
>> # scrolled through a few dozen changes, took a couple of seconds
>> git checkout openafs-stable-1_6_18
>>=20
>> At this point I got the following error:
>>=20
>> fatal: Unable to read current working directory: No such file or =
directory
>>=20
>> A "cd; cd -" cures this for a while, and there's no apparent data =
corruption. I'm still worried. The problem isn't 100% reproducible, but =
it doesn't take too may tries checking out random tags or branches.
>>=20
>> This was plain 1.6.18 + gerrit 12300 12301 12302 12274.
>>=20
>> Cache is on ext4, no separate partition, default size as set by our =
RPM (I think 100MB, but I don't have access to the VM right now to =
check).
>>=20
>> The small cache size may contribute to the problem. But I found no =
errors logged anywhere, and this shouldn't happen no matter how small =
the cache is.
>=20
> Please check if the cmdebug output is empty (I expect it is, but it is
> good to check).

It is empty.

>> NB we have a user report of exactly this problem happening frequently =
while just editing files in a local git repo in AFS space. The data is a =
bit sketchy, but it's probably Ubuntu 14.04 with its current default =
kernel and the openafs packages from Anders' ppa. I'll try to get us =
more data.
>>=20
>>=20
>> Any thoughts? For the time being I'm considering this a showstopper =
for
>> 1.6.18.1, and it looks like we're not quite there yet regarding Linux
>> 4.5, let alone 4.6 or the 4.7 due in a few weeks :-(
>=20
> Can you run the same test on a 4.4 kernel for comparison?

I tried under the last F22 kernel, 4.4.6-200.fc22. And ok, it's not 4.5 =
specific, though it seems to happen more frequently with 4.5.2 than with =
4.4.6.

By chance I found a pretty reliable reproducer:

	cd /vol/ume/root
	mkdir g; cd g
	git clone git://gerrit.openafs.org/openafs.git; sleep 180; git =
log

Note indeed no "cd openafs". Of course this should complain about the =
cwd not being a git repo. But most of the time it will complain about =
the cwd issue instead.

I'm planning to verify that plain 1.6.18 behaves the same on 4.4.6, and =
if it does I'll proceed with the 1.6.18.1 release.

I couldn't reproduce this with any EL clients, but those have larger =
caches (it's indeed 100 MB on that Fedora VM), so there's more to test. =
Help welcome...
=09


From jhgorse@gmail.com  Fri Jun 17 22:39:03 2016
From: jhgorse@gmail.com (Joe Gorse)
Date: Fri, 17 Jun 2016 17:39:03 -0400
Subject: [OpenAFS-devel] linux45: smoke test failed
In-Reply-To: <52B7EDC0-169C-4061-9DAB-F8656C6DB40C@desy.de>
References: <201647C0-EA11-4017-AF19-342BDAEFBD27@desy.de> <alpine.GSO.1.10.1606162244020.18480@multics.mit.edu>
 <52B7EDC0-169C-4061-9DAB-F8656C6DB40C@desy.de>
Message-ID: <CAFhSwD9SYCAu-_Qw2aMPN2UFA9y+hdmgAvutjibyittd68ZA1A@mail.gmail.com>

--001a114e45f4222851053580300b
Content-Type: text/plain; charset=UTF-8

Stephan

FWIW, I am able to reproduce a "cwd" message for "git log" command on
Fedora 23, 4.5.6-200.fc23.x86_64. "git log" reads:

fatal: Unable to read current working directory: No such file or directory

Though it should read:

fatal: Not a git repository (or any of the parent directories): .git


However, I am not having any trouble with the git checkout. It seems to
consistently work on Fedora 23. Even the "git checkout
openafs-stable-1_6_18". Perhaps try on 4.5.6 on Fedora?

Though I have seen some more of this issue on Debian 8 with kernel 4.6.0.
Three of three tests failed to checkout the openafs tree on this system. I
will test some other kernels on this system later and note anything
interesting.

Cheers,
Joe

On Fri, Jun 17, 2016 at 11:30 AM, Stephan Wiesand <stephan.wiesand@desy.de>
wrote:

>
> On Jun 17, 2016, at 04:45 , Benjamin Kaduk wrote:
>
> > On Thu, 16 Jun 2016, Stephan Wiesand wrote:
> >
> >> I smoke tested what was planned to be OpenAFS 1.6.18.1, as discussed in
> yesterday's release team meeting, on a Fedora 23 x86_64 VM with kernel
> 4.5.6-200 today. The result was disappointing:
> >>
> >> git clone git://gerrit.openafs.org/openafs.git
> >
> > Is the pwd the root of a volume?
>
> No, everything happens at least one level below.
>
> >> cd openafs
> >> git log
> >> # scrolled through a few dozen changes, took a couple of seconds
> >> git checkout openafs-stable-1_6_18
> >>
> >> At this point I got the following error:
> >>
> >> fatal: Unable to read current working directory: No such file or
> directory
> >>
> >> A "cd; cd -" cures this for a while, and there's no apparent data
> corruption. I'm still worried. The problem isn't 100% reproducible, but it
> doesn't take too may tries checking out random tags or branches.
> >>
> >> This was plain 1.6.18 + gerrit 12300 12301 12302 12274.
> >>
> >> Cache is on ext4, no separate partition, default size as set by our RPM
> (I think 100MB, but I don't have access to the VM right now to check).
> >>
> >> The small cache size may contribute to the problem. But I found no
> errors logged anywhere, and this shouldn't happen no matter how small the
> cache is.
> >
> > Please check if the cmdebug output is empty (I expect it is, but it is
> > good to check).
>
> It is empty.
>
> >> NB we have a user report of exactly this problem happening frequently
> while just editing files in a local git repo in AFS space. The data is a
> bit sketchy, but it's probably Ubuntu 14.04 with its current default kernel
> and the openafs packages from Anders' ppa. I'll try to get us more data.
> >>
> >>
> >> Any thoughts? For the time being I'm considering this a showstopper for
> >> 1.6.18.1, and it looks like we're not quite there yet regarding Linux
> >> 4.5, let alone 4.6 or the 4.7 due in a few weeks :-(
> >
> > Can you run the same test on a 4.4 kernel for comparison?
>
> I tried under the last F22 kernel, 4.4.6-200.fc22. And ok, it's not 4.5
> specific, though it seems to happen more frequently with 4.5.2 than with
> 4.4.6.
>
> By chance I found a pretty reliable reproducer:
>
>         cd /vol/ume/root
>         mkdir g; cd g
>         git clone git://gerrit.openafs.org/openafs.git; sleep 180; git log
>
> Note indeed no "cd openafs". Of course this should complain about the cwd
> not being a git repo. But most of the time it will complain about the cwd
> issue instead.
>
> I'm planning to verify that plain 1.6.18 behaves the same on 4.4.6, and if
> it does I'll proceed with the 1.6.18.1 release.
>
> I couldn't reproduce this with any EL clients, but those have larger
> caches (it's indeed 100 MB on that Fedora VM), so there's more to test.
> Help welcome...
>
>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>



-- 
Joe Gorse

C: 440-552-0730
LI: Joe Gorse <http://www.linkedin.com/pub/joe-gorse/7/12/397>

--001a114e45f4222851053580300b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Stephan<div><br></div><div>FWIW, I am able to reproduce a =
&quot;cwd&quot; message for &quot;git log&quot; command on Fedora 23, 4.5.6=
-200.fc23.x86_64. &quot;git log&quot; reads:</div>







<div><blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">=
<div>fatal: Unable to read current working directory: No such file or direc=
tory</div></blockquote>Though it should read:<div><blockquote style=3D"marg=
in:0px 0px 0px 40px;border:none;padding:0px"><div>fatal: Not a git reposito=
ry (or any of the parent directories): .git<br></div></blockquote><br></div=
></div><div>However, I am not having any trouble with the git checkout. It =
seems to consistently work on Fedora 23. Even the &quot;<span style=3D"font=
-size:12.8px">git checkout openafs-stable-1_6_18&quot;. Perhaps try on 4.5.=
6 on Fedora?</span></div><div><br></div><div>Though I have seen some more o=
f this issue on Debian 8 with kernel 4.6.0. Three of three tests failed to =
checkout the openafs tree on this system. I will test some other kernels on=
 this system later and note anything interesting.</div>







<div><br></div><div>Cheers,</div><div>Joe</div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Fri, Jun 17, 2016 at 11:30 AM, Steph=
an Wiesand <span dir=3D"ltr">&lt;<a href=3D"mailto:stephan.wiesand@desy.de"=
 target=3D"_blank">stephan.wiesand@desy.de</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D""><br>
On Jun 17, 2016, at 04:45 , Benjamin Kaduk wrote:<br>
<br>
&gt; On Thu, 16 Jun 2016, Stephan Wiesand wrote:<br>
&gt;<br>
&gt;&gt; I smoke tested what was planned to be OpenAFS 1.6.18.1, as discuss=
ed in yesterday&#39;s release team meeting, on a Fedora 23 x86_64 VM with k=
ernel 4.5.6-200 today. The result was disappointing:<br>
&gt;&gt;<br>
&gt;&gt; git clone git://<a href=3D"http://gerrit.openafs.org/openafs.git" =
rel=3D"noreferrer" target=3D"_blank">gerrit.openafs.org/openafs.git</a><br>
&gt;<br>
&gt; Is the pwd the root of a volume?<br>
<br>
</span>No, everything happens at least one level below.<br>
<span class=3D""><br>
&gt;&gt; cd openafs<br>
&gt;&gt; git log<br>
&gt;&gt; # scrolled through a few dozen changes, took a couple of seconds<b=
r>
&gt;&gt; git checkout openafs-stable-1_6_18<br>
&gt;&gt;<br>
&gt;&gt; At this point I got the following error:<br>
&gt;&gt;<br>
&gt;&gt; fatal: Unable to read current working directory: No such file or d=
irectory<br>
&gt;&gt;<br>
&gt;&gt; A &quot;cd; cd -&quot; cures this for a while, and there&#39;s no =
apparent data corruption. I&#39;m still worried. The problem isn&#39;t 100%=
 reproducible, but it doesn&#39;t take too may tries checking out random ta=
gs or branches.<br>
&gt;&gt;<br>
&gt;&gt; This was plain 1.6.18 + gerrit 12300 12301 12302 12274.<br>
&gt;&gt;<br>
&gt;&gt; Cache is on ext4, no separate partition, default size as set by ou=
r RPM (I think 100MB, but I don&#39;t have access to the VM right now to ch=
eck).<br>
&gt;&gt;<br>
&gt;&gt; The small cache size may contribute to the problem. But I found no=
 errors logged anywhere, and this shouldn&#39;t happen no matter how small =
the cache is.<br>
&gt;<br>
&gt; Please check if the cmdebug output is empty (I expect it is, but it is=
<br>
&gt; good to check).<br>
<br>
</span>It is empty.<br>
<span class=3D""><br>
&gt;&gt; NB we have a user report of exactly this problem happening frequen=
tly while just editing files in a local git repo in AFS space. The data is =
a bit sketchy, but it&#39;s probably Ubuntu 14.04 with its current default =
kernel and the openafs packages from Anders&#39; ppa. I&#39;ll try to get u=
s more data.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Any thoughts? For the time being I&#39;m considering this a showst=
opper for<br>
&gt;&gt; 1.6.18.1, and it looks like we&#39;re not quite there yet regardin=
g Linux<br>
&gt;&gt; 4.5, let alone 4.6 or the 4.7 due in a few weeks :-(<br>
&gt;<br>
&gt; Can you run the same test on a 4.4 kernel for comparison?<br>
<br>
</span>I tried under the last F22 kernel, 4.4.6-200.fc22. And ok, it&#39;s =
not 4.5 specific, though it seems to happen more frequently with 4.5.2 than=
 with 4.4.6.<br>
<br>
By chance I found a pretty reliable reproducer:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cd /vol/ume/root<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mkdir g; cd g<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 git clone git://<a href=3D"http://gerrit.openaf=
s.org/openafs.git" rel=3D"noreferrer" target=3D"_blank">gerrit.openafs.org/=
openafs.git</a>; sleep 180; git log<br>
<br>
Note indeed no &quot;cd openafs&quot;. Of course this should complain about=
 the cwd not being a git repo. But most of the time it will complain about =
the cwd issue instead.<br>
<br>
I&#39;m planning to verify that plain 1.6.18 behaves the same on 4.4.6, and=
 if it does I&#39;ll proceed with the 1.6.18.1 release.<br>
<br>
I couldn&#39;t reproduce this with any EL clients, but those have larger ca=
ches (it&#39;s indeed 100 MB on that Fedora VM), so there&#39;s more to tes=
t. Help welcome...<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
_______________________________________________<br>
OpenAFS-devel mailing list<br>
<a href=3D"mailto:OpenAFS-devel@openafs.org">OpenAFS-devel@openafs.org</a><=
br>
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-devel" rel=3D=
"noreferrer" target=3D"_blank">https://lists.openafs.org/mailman/listinfo/o=
penafs-devel</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=
=3D"ltr"><div>Joe Gorse<div><font face=3D"Calibri" size=3D"1"><br></font></=
div><div><font face=3D"Calibri" size=3D"1"><div style=3D"font-family:arial;=
font-size:small"><span style=3D"font-family:arial;background-color:rgb(255,=
255,255)"><font size=3D"1">C:=C2=A0</font></span><span style=3D"background-=
color:rgb(255,255,255);font-size:x-small"><a value=3D"+14402344531"><font c=
olor=3D"#0000cc" face=3D"Helvetica">440-552-0730</font></a></span></div><di=
v style=3D"font-family:arial;font-size:small"><span style=3D"font-family:ar=
ial;background-color:rgb(255,255,255)"><font size=3D"1">LI: <a href=3D"http=
://www.linkedin.com/pub/joe-gorse/7/12/397" target=3D"_blank">Joe Gorse</a>=
</font></span></div></font></div></div></div></div>
</div>

--001a114e45f4222851053580300b--

From deywos@mit.edu  Sat Jun 18 06:28:12 2016
From: deywos@mit.edu (Deven Lahoti)
Date: Sat, 18 Jun 2016 00:28:12 -0500
Subject: [OpenAFS-devel] OpenAFS and grsecurity
In-Reply-To: <CANGLR7s8tAw-Qqyzkf7CmiG_-b3su6vEf3Z5xLKfr8bGr4=0JQ@mail.gmail.com>
References: <CANGLR7s3wzpQuXqUdOc7-ZGCkSbY2EDPT=TB=zAupx8B_Pjp3A@mail.gmail.com>
 <0fdcf908-0061-6607-400c-6c6356084b95@auristor.com> <CANGLR7s8tAw-Qqyzkf7CmiG_-b3su6vEf3Z5xLKfr8bGr4=0JQ@mail.gmail.com>
Message-ID: <CANGLR7uhYNEMxjwL6NZ8KCPioS9uwtxxdNWKSvoEPFDhBSJXmQ@mail.gmail.com>

--001a1143ad7c189475053586bf50
Content-Type: text/plain; charset=UTF-8

Okay, I've patched the m4 macros to properly detect config options from the
grsec kernel and have added tests to make sure we're using a compatible
compiler for designated initializers:

http://web.mit.edu/deywos/www/openafs-grsec.patch

deven

--001a1143ad7c189475053586bf50
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Okay, I&#39;ve patched the m4 macros to properly dete=
ct config options from the grsec kernel and have added tests to make sure w=
e&#39;re using a compatible compiler for designated initializers:<br><br><a=
 href=3D"http://web.mit.edu/deywos/www/openafs-grsec.patch" target=3D"_blan=
k">http://web.mit.edu/deywos/www/openafs-grsec.patch</a><br><br></div>deven=
<br></div>

--001a1143ad7c189475053586bf50--

From stephan.wiesand@desy.de  Sat Jun 18 19:27:34 2016
From: stephan.wiesand@desy.de (Stephan Wiesand)
Date: Sat, 18 Jun 2016 20:27:34 +0200
Subject: [OpenAFS-devel] linux45: smoke test failed
In-Reply-To: <CAFhSwD9SYCAu-_Qw2aMPN2UFA9y+hdmgAvutjibyittd68ZA1A@mail.gmail.com>
References: <201647C0-EA11-4017-AF19-342BDAEFBD27@desy.de> <alpine.GSO.1.10.1606162244020.18480@multics.mit.edu> <52B7EDC0-169C-4061-9DAB-F8656C6DB40C@desy.de> <CAFhSwD9SYCAu-_Qw2aMPN2UFA9y+hdmgAvutjibyittd68ZA1A@mail.gmail.com>
Message-ID: <74A6EE19-8EC5-4687-BD30-DD128F70B55C@desy.de>

Joe,

thanks for the feedback.

On Jun 17, 2016, at 23:39 , Joe Gorse wrote:
> FWIW, I am able to reproduce a "cwd" message for "git log" command on
> Fedora 23, 4.5.6-200.fc23.x86_64. "git log" reads:
>=20
> fatal: Unable to read current working directory: No such file or =
directory
>=20
> Though it should read:
>=20
> fatal: Not a git repository (or any of the parent directories): .git

Exactly the problem I'm seeing.
>=20
> However, I am not having any trouble with the git checkout. It seems =
to
> consistently work on Fedora 23. Even the "git checkout
> openafs-stable-1_6_18". Perhaps try on 4.5.6 on Fedora?

That's where I started, see the first message in this thread. And in all =
cases, the git checkout actually works. I'm just using it to trigger the =
cwd problem - there are probably many other ways. Note that also "git =
log" is just one way of exposing the problem

> Though I have seen some more of this issue on Debian 8 with kernel =
4.6.0.
> Three of three tests failed to checkout the openafs tree on this =
system. I
> will test some other kernels on this system later and note anything
> interesting.

Sounds even considerably worse :-(

Any errors logged? Does the client actually have some variant of gerrit =
12228 applied?

Cheers,
	Stephan

> Cheers,
> Joe
>=20
> On Fri, Jun 17, 2016 at 11:30 AM, Stephan Wiesand =
<stephan.wiesand@desy.de>
> wrote:
>=20
>>=20
>> On Jun 17, 2016, at 04:45 , Benjamin Kaduk wrote:
>>=20
>>> On Thu, 16 Jun 2016, Stephan Wiesand wrote:
>>>=20
>>>> I smoke tested what was planned to be OpenAFS 1.6.18.1, as =
discussed in
>> yesterday's release team meeting, on a Fedora 23 x86_64 VM with =
kernel
>> 4.5.6-200 today. The result was disappointing:
>>>>=20
>>>> git clone git://gerrit.openafs.org/openafs.git
>>>=20
>>> Is the pwd the root of a volume?
>>=20
>> No, everything happens at least one level below.
>>=20
>>>> cd openafs
>>>> git log
>>>> # scrolled through a few dozen changes, took a couple of seconds
>>>> git checkout openafs-stable-1_6_18
>>>>=20
>>>> At this point I got the following error:
>>>>=20
>>>> fatal: Unable to read current working directory: No such file or
>> directory
>>>>=20
>>>> A "cd; cd -" cures this for a while, and there's no apparent data
>> corruption. I'm still worried. The problem isn't 100% reproducible, =
but it
>> doesn't take too may tries checking out random tags or branches.
>>>>=20
>>>> This was plain 1.6.18 + gerrit 12300 12301 12302 12274.
>>>>=20
>>>> Cache is on ext4, no separate partition, default size as set by our =
RPM
>> (I think 100MB, but I don't have access to the VM right now to =
check).
>>>>=20
>>>> The small cache size may contribute to the problem. But I found no
>> errors logged anywhere, and this shouldn't happen no matter how small =
the
>> cache is.
>>>=20
>>> Please check if the cmdebug output is empty (I expect it is, but it =
is
>>> good to check).
>>=20
>> It is empty.
>>=20
>>>> NB we have a user report of exactly this problem happening =
frequently
>> while just editing files in a local git repo in AFS space. The data =
is a
>> bit sketchy, but it's probably Ubuntu 14.04 with its current default =
kernel
>> and the openafs packages from Anders' ppa. I'll try to get us more =
data.
>>>>=20
>>>>=20
>>>> Any thoughts? For the time being I'm considering this a showstopper =
for
>>>> 1.6.18.1, and it looks like we're not quite there yet regarding =
Linux
>>>> 4.5, let alone 4.6 or the 4.7 due in a few weeks :-(
>>>=20
>>> Can you run the same test on a 4.4 kernel for comparison?
>>=20
>> I tried under the last F22 kernel, 4.4.6-200.fc22. And ok, it's not =
4.5
>> specific, though it seems to happen more frequently with 4.5.2 than =
with
>> 4.4.6.
>>=20
>> By chance I found a pretty reliable reproducer:
>>=20
>>        cd /vol/ume/root
>>        mkdir g; cd g
>>        git clone git://gerrit.openafs.org/openafs.git; sleep 180; git =
log
>>=20
>> Note indeed no "cd openafs". Of course this should complain about the =
cwd
>> not being a git repo. But most of the time it will complain about the =
cwd
>> issue instead.
>>=20
>> I'm planning to verify that plain 1.6.18 behaves the same on 4.4.6, =
and if
>> it does I'll proceed with the 1.6.18.1 release.
>>=20
>> I couldn't reproduce this with any EL clients, but those have larger
>> caches (it's indeed 100 MB on that Fedora VM), so there's more to =
test.
>> Help welcome...
>>=20
>>=20
>> _______________________________________________
>> OpenAFS-devel mailing list
>> OpenAFS-devel@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-devel
>>=20
>=20
>=20
>=20
> --=20
> Joe Gorse
>=20
> C: 440-552-0730
> LI: Joe Gorse <http://www.linkedin.com/pub/joe-gorse/7/12/397>

--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany


From richter@richtercloud.de  Mon Jun 20 08:46:06 2016
From: richter@richtercloud.de (Karl-Philipp Richter)
Date: Mon, 20 Jun 2016 09:46:06 +0200
Subject: [OpenAFS-devel] SIGKILL ignored by afsd
Message-ID: <57679F3E.50900@richtercloud.de>

I'm experiencing the strange issue that sending `SIGKILL` to `afsd`
using `sudo pkill -KILL afsd` (returns with `0`) doesn't have any effect
on afsd which remains running (in sleeping state) according to `ps -A |
grep afs`. Afaik that's impossible, so I assume it's a bug. Since I
don't experienced this issue with any other process ever I assume it's
an OpenAFS and not a Linux bug. Should I thus file it?

experienced with OpenAFS 1.6.18-1~ppa0~ubuntu16.04.1 on Ubuntu 16.04
with Linux 4.4.0 and 4.5.7

-Kalle

From haba@kth.se  Mon Jun 20 09:04:21 2016
From: haba@kth.se (Harald Barth)
Date: Mon, 20 Jun 2016 10:04:21 +0200 (CEST)
Subject: [OpenAFS-devel] SIGKILL ignored by afsd
In-Reply-To: <57679F3E.50900@richtercloud.de>
References: <57679F3E.50900@richtercloud.de>
Message-ID: <20160620.100421.2117454140190859090.haba@habook.pdc.kth.se>


> I'm experiencing the strange issue that sending `SIGKILL` to `afsd`
> using `sudo pkill -KILL afsd` (returns with `0`) doesn't have any effect
> on afsd which remains running (...)

I'd guess afsd is waiting for a syscall return.

> an OpenAFS and not a Linux bug. Should I thus file it?

Signals are (for all processes in Linux) are handled after
that the syscall returns.

Harald.

From mmeffie@sinenomine.net  Mon Jun 20 15:12:08 2016
From: mmeffie@sinenomine.net (Michael Meffie)
Date: Mon, 20 Jun 2016 10:12:08 -0400
Subject: [OpenAFS-devel] SIGKILL ignored by afsd
In-Reply-To: <20160620.100421.2117454140190859090.haba@habook.pdc.kth.se>
References: <57679F3E.50900@richtercloud.de>
 <20160620.100421.2117454140190859090.haba@habook.pdc.kth.se>
Message-ID: <20160620101208.434db8ee5610ddcb319edb4e@sinenomine.net>

On Mon, 20 Jun 2016 10:04:21 +0200 (CEST)
Harald Barth <haba@kth.se> wrote:

> 
> 
> > I'm experiencing the strange issue that sending `SIGKILL` to `afsd`
> > using `sudo pkill -KILL afsd` (returns with `0`) doesn't have any effect
> > on afsd which remains running (...)
> 
> I'd guess afsd is waiting for a syscall return.

Hello,

It is possible the "afsd" progress Kalle was trying to kill was actually
the afsdb dns lookup helper daemon, which normally is in a syscall
until it is dispatched to do some work.

> 
> > an OpenAFS and not a Linux bug. Should I thus file it?
> 
> Signals are (for all processes in Linux) are handled after
> that the syscall returns.


-- 
Michael Meffie <mmeffie@sinenomine.net>

From kaduk@MIT.EDU  Tue Jun 21 20:55:20 2016
From: kaduk@MIT.EDU (Benjamin Kaduk)
Date: Tue, 21 Jun 2016 15:55:20 -0400 (EDT)
Subject: [OpenAFS-devel] OpenAFS and grsecurity
In-Reply-To: <CANGLR7uhYNEMxjwL6NZ8KCPioS9uwtxxdNWKSvoEPFDhBSJXmQ@mail.gmail.com>
References: <CANGLR7s3wzpQuXqUdOc7-ZGCkSbY2EDPT=TB=zAupx8B_Pjp3A@mail.gmail.com> <0fdcf908-0061-6607-400c-6c6356084b95@auristor.com> <CANGLR7s8tAw-Qqyzkf7CmiG_-b3su6vEf3Z5xLKfr8bGr4=0JQ@mail.gmail.com>
 <CANGLR7uhYNEMxjwL6NZ8KCPioS9uwtxxdNWKSvoEPFDhBSJXmQ@mail.gmail.com>
Message-ID: <alpine.GSO.1.10.1606211552510.18480@multics.mit.edu>

Thanks for making the updates.  The patch is less likely to get lost if it
is submitted to https://gerrit.openafs.org, see
href="https://wiki.openafs.org/GitDevelopers/#Sharing your code with us".

A couple notes just from glancing at it: there is no need to explicitly
initialize .foo to 0 when using the named initializers, and 0 is also
better spelled NULL for function pointers.

-Ben

On Sat, 18 Jun 2016, Deven Lahoti wrote:

> Okay, I've patched the m4 macros to properly detect config options from the
> grsec kernel and have added tests to make sure we're using a compatible
> compiler for designated initializers:
>
> http://web.mit.edu/deywos/www/openafs-grsec.patch
>
> deven
>

From deywos@mit.edu  Wed Jun 22 00:20:25 2016
From: deywos@mit.edu (Deven Lahoti)
Date: Tue, 21 Jun 2016 18:20:25 -0500
Subject: [OpenAFS-devel] OpenAFS and grsecurity
In-Reply-To: <alpine.GSO.1.10.1606211552510.18480@multics.mit.edu>
References: <CANGLR7s3wzpQuXqUdOc7-ZGCkSbY2EDPT=TB=zAupx8B_Pjp3A@mail.gmail.com>
 <0fdcf908-0061-6607-400c-6c6356084b95@auristor.com> <CANGLR7s8tAw-Qqyzkf7CmiG_-b3su6vEf3Z5xLKfr8bGr4=0JQ@mail.gmail.com>
 <CANGLR7uhYNEMxjwL6NZ8KCPioS9uwtxxdNWKSvoEPFDhBSJXmQ@mail.gmail.com> <alpine.GSO.1.10.1606211552510.18480@multics.mit.edu>
Message-ID: <CANGLR7uMgN2kWc_2K7fioa_rasEW+FFVKVS57Vx2rRzCk6jOgQ@mail.gmail.com>

Done.

https://gerrit.openafs.org/#/c/12313/

Yeah, I'm not sure why I explicitly initialized everything before, but
I fixed it now.

On Tue, Jun 21, 2016 at 2:55 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> Thanks for making the updates.  The patch is less likely to get lost if it
> is submitted to https://gerrit.openafs.org, see
> href="https://wiki.openafs.org/GitDevelopers/#Sharing your code with us".
>
> A couple notes just from glancing at it: there is no need to explicitly
> initialize .foo to 0 when using the named initializers, and 0 is also
> better spelled NULL for function pointers.
>
> -Ben
>
> On Sat, 18 Jun 2016, Deven Lahoti wrote:
>
> > Okay, I've patched the m4 macros to properly detect config options from the
> > grsec kernel and have added tests to make sure we're using a compatible
> > compiler for designated initializers:
> >
> > http://web.mit.edu/deywos/www/openafs-grsec.patch
> >
> > deven
> >

From kaduk@MIT.EDU  Fri Jun 24 00:07:28 2016
From: kaduk@MIT.EDU (Benjamin Kaduk)
Date: Thu, 23 Jun 2016 19:07:28 -0400 (EDT)
Subject: [OpenAFS-devel] SIGKILL ignored by afsd
In-Reply-To: <20160620101208.434db8ee5610ddcb319edb4e@sinenomine.net>
References: <57679F3E.50900@richtercloud.de> <20160620.100421.2117454140190859090.haba@habook.pdc.kth.se> <20160620101208.434db8ee5610ddcb319edb4e@sinenomine.net>
Message-ID: <alpine.GSO.1.10.1606231904480.18480@multics.mit.edu>

On Mon, 20 Jun 2016, Michael Meffie wrote:

> On Mon, 20 Jun 2016 10:04:21 +0200 (CEST)
> Harald Barth <haba@kth.se> wrote:
>
> >
> >
> > > I'm experiencing the strange issue that sending `SIGKILL` to `afsd`
> > > using `sudo pkill -KILL afsd` (returns with `0`) doesn't have any effect
> > > on afsd which remains running (...)
> >
> > I'd guess afsd is waiting for a syscall return.
>
> Hello,
>
> It is possible the "afsd" progress Kalle was trying to kill was actually
> the afsdb dns lookup helper daemon, which normally is in a syscall
> until it is dispatched to do some work.

Well, pkill will hit all matching processes.

But, to first order, all afsd processes should be thought of as kernel
threads, and so are not subject to normal signals.

For Kalle, to be explicit: this is not a bug.  afsd processes should not
terminate until the AFS client is stopped, which is done via "umount /afs"
(normally) or "afsd -shutdown" (if something went wrong ... hopefully it
would actually work).

-Ben

From richter@richtercloud.de  Fri Jun 24 09:16:30 2016
From: richter@richtercloud.de (Karl-Philipp Richter)
Date: Fri, 24 Jun 2016 10:16:30 +0200
Subject: [OpenAFS-devel] Delay of minor releases on master PPA
Message-ID: <576CEC5E.2080603@richtercloud.de>

Hi,
I was wondering if there's a policy about providing minor releases in
the [Ubuntu OpenAFS master
PPA](https://launchpad.net/~openafs/+archive/ubuntu/master), like the
recently released 1.6.18.1. As of now it's still 1.6.18. If it's not
done by a robot or delayed for a reason, I'd be happy if you'd provide
the release in the PPA.

-Kalle

From kaduk@MIT.EDU  Fri Jun 24 16:28:50 2016
From: kaduk@MIT.EDU (Benjamin Kaduk)
Date: Fri, 24 Jun 2016 11:28:50 -0400 (EDT)
Subject: [OpenAFS-devel] Delay of minor releases on master PPA
In-Reply-To: <576CEC5E.2080603@richtercloud.de>
References: <576CEC5E.2080603@richtercloud.de>
Message-ID: <alpine.GSO.1.10.1606241124330.18480@multics.mit.edu>

On Fri, 24 Jun 2016, Karl-Philipp Richter wrote:

> Hi,
> I was wondering if there's a policy about providing minor releases in
> the [Ubuntu OpenAFS master
> PPA](https://launchpad.net/~openafs/+archive/ubuntu/master), like the
> recently released 1.6.18.1. As of now it's still 1.6.18. If it's not
> done by a robot or delayed for a reason, I'd be happy if you'd provide
> the release in the PPA.

It is not done by a robot.  The OpenAFS team on launchpad
(https://launchpad.net/~openafs) manages it, which has a single member; if
you are logged in to launchpad, https://launchpad.net/~anders-kaseorg will
display a direct email address for Anders.

The Ubuntu packaging is usually derived from the Debian packaging for a
given release, but sometimes when I am slow to update Debian, Anders will
take the update in Ubuntu before it makes it into Debian.  I may have time
to update Debian this weekend, but my schedule is pretty busy at the
moment.

-Ben

From stephan.wiesand@desy.de  Fri Jun 24 19:59:53 2016
From: stephan.wiesand@desy.de (Stephan Wiesand)
Date: Fri, 24 Jun 2016 20:59:53 +0200
Subject: [OpenAFS-devel] Delay of minor releases on master PPA
In-Reply-To: <alpine.GSO.1.10.1606241124330.18480@multics.mit.edu>
References: <576CEC5E.2080603@richtercloud.de> <alpine.GSO.1.10.1606241124330.18480@multics.mit.edu>
Message-ID: <7284568B-DAFE-495F-9247-972CD409FB6A@desy.de>

On Jun 24, 2016, at 17:28 , Benjamin Kaduk wrote:

> On Fri, 24 Jun 2016, Karl-Philipp Richter wrote:
>=20
>> Hi,
>> I was wondering if there's a policy about providing minor releases in
>> the [Ubuntu OpenAFS master
>> PPA](https://launchpad.net/~openafs/+archive/ubuntu/master), like the
>> recently released 1.6.18.1. As of now it's still 1.6.18. If it's not
>> done by a robot or delayed for a reason, I'd be happy if you'd =
provide
>> the release in the PPA.
>=20
> It is not done by a robot.  The OpenAFS team on launchpad
> (https://launchpad.net/~openafs) manages it, which has a single =
member; if
> you are logged in to launchpad, https://launchpad.net/~anders-kaseorg =
will
> display a direct email address for Anders.
>=20
> The Ubuntu packaging is usually derived from the Debian packaging for =
a
> given release, but sometimes when I am slow to update Debian, Anders =
will
> take the update in Ubuntu before it makes it into Debian.  I may have =
time
> to update Debian this weekend, but my schedule is pretty busy at the
> moment.

Also please note that the time of release is fairly unpredictable. A =
couple of hours before you received the announcement, it was far from =
clear that 1.6.18.1 would ship that day. It could well have been =
postponed for a couple of days or even weeks. Please don't complain if =
downstream packagers don't jump on the release within hours. Maybe =
rather ask them (or us) how to help?

- Stephan