Received-SPF: pass (google.com: domain of linux-kernel+bounces-58703-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <38f51dbb-65aa-4ec2-bed2-e914aef27d25@vrvis.at>
 <ZcNdzZVPD76uSbps@eldamar.lan> <CADKFtnRfqi-A_Ak_S-YC52jPn604+ekcmCmNoTA_yEpAcW4JJg@mail.gmail.com>
 <1d4c7d06-0c02-4adb-a2a3-ec85fd802ddb@vrvis.at> <CADKFtnQUQt=M32tYhcutP0q6exOgk9R6xgxddDdewbms+7xwTQ@mail.gmail.com>
In-Reply-To: <CADKFtnQUQt=M32tYhcutP0q6exOgk9R6xgxddDdewbms+7xwTQ@mail.gmail.com>
From: Jordan Rife <jrife@google.com>
Date: Thu, 8 Feb 2024 13:17:11 -0800
Message-ID: <CADKFtnQnz0NEWQT2K1AGARY5=_o2dhS3gRyMo-=9kuxqeQvcqQ@mail.gmail.com>
Subject: Re: [regression 6.1.76] dlm: cannot start dlm midcomms -97 after
 backport of e9cdebbe23f1 ("dlm: use kernel_connect() and kernel_bind()")
To: Valentin Kleibel <valentin@vrvis.at>
Cc: Salvatore Bonaccorso <carnil@debian.org>, David Teigland <teigland@redhat.com>, 
	Alexander Aring <aahringo@redhat.com>, 1063338@bugs.debian.org, gfs2@lists.linux.dev, 
	linux-kernel@vger.kernel.org, stable@vger.kernel.org, 
	gregkh@linuxfoundation.org, regressions@lists.linux.dev
Content-Type: multipart/mixed; boundary="0000000000007a52e50610e556ed"

--0000000000007a52e50610e556ed
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Valentin,

Would you be able to confirm that the attached patch fixes your issue as we=
ll?

-Jordan

On Thu, Feb 8, 2024 at 9:42=E2=80=AFAM Jordan Rife <jrife@google.com> wrote=
:
>
> On Thu, Feb 8, 2024 at 3:37=E2=80=AFAM Valentin Kleibel <valentin@vrvis.a=
t> wrote:
> >
> > Hi Jordan, hi all
> >
> > > Just a quick look comparing dlm_tcp_listen_bind between the latest 6.=
1
> > > and 6.6 stable branches,
> > > it looks like there is a mismatch here with the dlm_local_addr[0] par=
ameter.
> > >
> > > 6.1
> > > ----
> > >
> > > static int dlm_tcp_listen_bind(struct socket *sock)
> > > {
> > > int addr_len;
> > >
> > > /* Bind to our port */
> > > make_sockaddr(dlm_local_addr[0], dlm_config.ci_tcp_port, &addr_len);
> > > return kernel_bind(sock, (struct sockaddr *)&dlm_local_addr[0],
> > >     addr_len);
> > > }
> > >
> > > 6.6
> > > ----
> > > static int dlm_tcp_listen_bind(struct socket *sock)
> > > {
> > > int addr_len;
> > >
> > > /* Bind to our port */
> > > make_sockaddr(&dlm_local_addr[0], dlm_config.ci_tcp_port, &addr_len);
> > > return kernel_bind(sock, (struct sockaddr *)&dlm_local_addr[0],
> > >     addr_len);
> > > }
> > >
> > > 6.6 contains commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs on h=
eap) which
> > > changed
> > >
> > > static struct sockaddr_storage *dlm_local_addr[DLM_MAX_ADDR_COUNT];
> > >
> > > to
> > >
> > > static struct sockaddr_storage dlm_local_addr[DLM_MAX_ADDR_COUNT];
> > >
> > > It looks like kernel_bind() in 6.1 needs to be modified to match.
> >
> > We tried to apply commit c51c9cd8 (fs: dlm: don't put dlm_local_addrs o=
n
> > heap) to the debian kernel 6.1.76 and came up with the attached patch.
> > Besides the different offsets there is a slight change dlm_tcp_bind()
> > where in 6.1.76 kernel_bind() is used instead of sock->ops->bind() in
> > the original commit.
> >
> > This patch solves the issue we experienced.
> >
> > Thanks for your help,
> > Valentin
>
> Good to hear that works for you! We should fix this in the 6.1 stable
> kernel as well.
>
> IMO it may be less risky and simpler to fix the backport of my patch
> e9cdebbe23f1 ("dlm: use kernel_connect() and
> kernel_bind()") and just switch (struct sockaddr *)&dlm_local_addr[0]
> to (struct sockaddr *)dlm_local_addr[0]
> in the call to kernel_bind() rather than backporting c51c9cd8 (fs:
> dlm: don't put dlm_local_addrs on
> heap) to 6.1.
>
> I will have some time soon to fix the 6.1 backport, but it may make
> sense just to revert in the meantime.
>
> -Jordan

--0000000000007a52e50610e556ed
Content-Type: text/x-patch; charset="US-ASCII"; 
	name="0001-dlm-Treat-dlm_local_addr-0-as-sockaddr_storage.patch"
Content-Disposition: attachment; 
	filename="0001-dlm-Treat-dlm_local_addr-0-as-sockaddr_storage.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_lsdpwbpg0>
X-Attachment-Id: f_lsdpwbpg0

RnJvbSBkZWM1ZmZkMzA5OTY3ZTQyOWI2MTZhOWQ0OTgwMzdhNWViNDM3YzU0IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBKb3JkYW4gUmlmZSA8anJpZmVAZ29vZ2xlLmNvbT4KRGF0ZTog
VGh1LCA4IEZlYiAyMDI0IDEyOjA5OjU1IC0wNjAwClN1YmplY3Q6IFtQQVRDSF0gZGxtOiBUcmVh
dCBkbG1fbG9jYWxfYWRkclswXSBhcyBzb2NrYWRkcl9zdG9yYWdlICoKCkJhY2twb3J0IGUxMWRl
YTggKCJkbG06IHVzZSBrZXJuZWxfY29ubmVjdCgpIGFuZCBrZXJuZWxfYmluZCgpIikgdG8KTGlu
dXggc3RhYmxlIDYuMSBjYXVzZWQgYSByZWdyZXNzaW9uLiBUaGUgb3JpZ2luYWwgcGF0Y2ggZXhw
ZWN0ZWQKZGxtX2xvY2FsX2FkZHJzWzBdIHRvIGJlIG9mIHR5cGUgc29ja2FkZHJfc3RvcmFnZSwg
YmVjYXVzZSBjNTFjOWNkICgiZnM6CmRsbTogZG9uJ3QgcHV0IGRsbV9sb2NhbF9hZGRycyBvbiBo
ZWFwIikgY2hhbmdlZCBpdHMgdHlwZSBmcm9tCnNvY2thZGRyX3N0b3JhZ2UqIHRvIHNvY2thZGRy
X3N0b3JhZ2UgaW4gTGludXggNi41KyB3aGlsZSBpbiBvbGRlciBMaW51eAp2ZXJzaW9ucyB0aGlz
IGlzIHN0aWxsIHRoZSBvcmlnaW5hbCBzb2NrYWRkcl9zdG9yYWdlKi4KCkxpbms6IGh0dHBzOi8v
YnVncy5kZWJpYW4ub3JnL2NnaS1iaW4vYnVncmVwb3J0LmNnaT9idWc9MTA2MzMzOApGaXhlczog
ZTExZGVhOCAoImRsbTogdXNlIGtlcm5lbF9jb25uZWN0KCkgYW5kIGtlcm5lbF9iaW5kKCkiKQpT
aWduZWQtb2ZmLWJ5OiBKb3JkYW4gUmlmZSA8anJpZmVAZ29vZ2xlLmNvbT4KLS0tCiBmcy9kbG0v
bG93Y29tbXMuYyB8IDIgKy0KIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMSBkZWxl
dGlvbigtKQoKZGlmZiAtLWdpdCBhL2ZzL2RsbS9sb3djb21tcy5jIGIvZnMvZGxtL2xvd2NvbW1z
LmMKaW5kZXggNzJmMzRmOTZkMDE1NS4uODQyNjA3M2U3M2NmMiAxMDA2NDQKLS0tIGEvZnMvZGxt
L2xvd2NvbW1zLmMKKysrIGIvZnMvZGxtL2xvd2NvbW1zLmMKQEAgLTE5MDAsNyArMTkwMCw3IEBA
IHN0YXRpYyBpbnQgZGxtX3RjcF9saXN0ZW5fYmluZChzdHJ1Y3Qgc29ja2V0ICpzb2NrKQogCiAJ
LyogQmluZCB0byBvdXIgcG9ydCAqLwogCW1ha2Vfc29ja2FkZHIoZGxtX2xvY2FsX2FkZHJbMF0s
IGRsbV9jb25maWcuY2lfdGNwX3BvcnQsICZhZGRyX2xlbik7Ci0JcmV0dXJuIGtlcm5lbF9iaW5k
KHNvY2ssIChzdHJ1Y3Qgc29ja2FkZHIgKikmZGxtX2xvY2FsX2FkZHJbMF0sCisJcmV0dXJuIGtl
cm5lbF9iaW5kKHNvY2ssIChzdHJ1Y3Qgc29ja2FkZHIgKilkbG1fbG9jYWxfYWRkclswXSwKIAkJ
CSAgIGFkZHJfbGVuKTsKIH0KIAotLSAKMi40My4wLjY4Ny5nMzhhYTY1NTliMC1nb29nCgo=
--0000000000007a52e50610e556ed--