[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH] EDAC/i10nm: Add Intel Grand Ridge micro-server support
From: Qiuxu Zhuo
commit e77086c3750834553cf6fd2255c5f3ee04843ed8 upstream.
The Grand Ridge CPU model uses similar memory controller registers with
Granite Rapids server. Add Grand Ridge CPU model ID for EDAC support.
Tested-by: Ricardo Neri
Signed-off-by: Qiuxu Zhuo
Signed-off-by: Tony Luck
Link: https://lore.kernel.org/r/20240129062040.60809-3-qiuxu.z...@intel.com
Signed-off-by: Yongxin Liu
---
drivers/edac/i10nm_base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/edac/i10nm_base.c b/drivers/edac/i10nm_base.c
index 04ca336b879f..2f2f24f829de 100644
--- a/drivers/edac/i10nm_base.c
+++ b/drivers/edac/i10nm_base.c
@@ -907,6 +907,7 @@ static const struct x86_cpu_id i10nm_cpuids[] = {
X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(EMERALDRAPIDS_X,
X86_STEPPINGS(0x0, 0xf), _cfg),
X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(GRANITERAPIDS_X,
X86_STEPPINGS(0x0, 0xf), _cfg),
X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(ATOM_CRESTMONT_X,
X86_STEPPINGS(0x0, 0xf), _cfg),
+ X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(ATOM_CRESTMONT,
X86_STEPPINGS(0x0, 0xf), _cfg),
{}
};
MODULE_DEVICE_TABLE(x86cpu, i10nm_cpuids);
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13862):
https://lists.yoctoproject.org/g/linux-yocto/message/13862
Mute This Topic: https://lists.yoctoproject.org/mt/105705247/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 0/1] Fix Intel Grand Ridge cannot boot issue
Hi Bruce,
Intel Grand Ridge cannot boot after the backport of commit a6a5006dad57
("iommu/vt-d: Retrieve IOMMU perfmon capability information"), in v6.1.83.
This patch is the second patch of the following patch series in mainline.
d8a7c0cf05a2 2023-02-03 11:06 Kan Liangiommu/vt-d: Enable IOMMU perfmon
support
4a0d4265659b 2023-02-03 11:06 Kan Liangiommu/vt-d: Add IOMMU perfmon
overflow handler support
46284c6ceb5e 2023-02-03 11:06 Kan Liangiommu/vt-d: Support cpumask for
IOMMU perfmon
7232ab8b89e9 2023-02-03 11:06 Kan Liangiommu/vt-d: Add IOMMU perfmon
support
dc57875866ab 2023-02-03 11:06 Kan Liangiommu/vt-d: Support Enhanced
Command Interface
a6a5006dad57 2023-02-03 11:06 Kan Liangiommu/vt-d: Retrieve IOMMU
perfmon capability information
4db96bfe9d77 2023-02-03 11:06 Kan Liangiommu/vt-d: Support size of the
register set in DRHD
It is strange only one patch was backported in linux-stable v6.1.
Because in order to eable IOMMU perfmon, all patches should be backported.
Anyway, we need to back port the first patch to boot kernel on newer hardware,
such as Intel GrandRidge.
So please help to merge this patch to v6.1/standard/x86 and
v6.1/standard/preempt-rt/x86.
Thanks,
Yongxin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13861):
https://lists.yoctoproject.org/g/linux-yocto/message/13861
Mute This Topic: https://lists.yoctoproject.org/mt/105704897/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][v6.1/standard/x86 and v6.1/standard/preempt-rt/x86][PATCH 1/1] iommu/vt-d: Support size of the register set in DRHD
From: Kan Liang
commit 4db96bfe9d7772d6ddedd62ce478895999043fd7 upstream.
A new field, which indicates the size of the remapping hardware register
set for this remapping unit, is introduced in the DMA-remapping hardware
unit definition (DRHD) structure with the VT-d Spec 4.0. With this
information, SW doesn't need to 'guess' the size of the register set
anymore.
Update the struct acpi_dmar_hardware_unit to reflect the field. Store the
size of the register set in struct dmar_drhd_unit for each dmar device.
The 'size' information is ResvZ for the old BIOS and platforms. Fall back
to the old guessing method. There is nothing changed.
Signed-off-by: Kan Liang
Link:
https://lore.kernel.org/r/20230128200428.1459118-2-kan.li...@linux.intel.com
Signed-off-by: Lu Baolu
Signed-off-by: Joerg Roedel
Signed-off-by: Yongxin Liu
---
drivers/iommu/intel/dmar.c | 11 +++
include/acpi/actbl1.h | 2 +-
include/linux/dmar.h | 1 +
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 4759f79ad7b9..b8dd628125f4 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -428,6 +428,8 @@ static int dmar_parse_one_drhd(struct acpi_dmar_header
*header, void *arg)
memcpy(dmaru->hdr, header, header->length);
dmaru->reg_base_addr = drhd->address;
dmaru->segment = drhd->segment;
+ /* The size of the register set is 2 ^ N 4 KB pages. */
+ dmaru->reg_size = 1UL << (drhd->size + 12);
dmaru->include_all = drhd->flags & 0x1; /* BIT0: INCLUDE_ALL */
dmaru->devices = dmar_alloc_dev_scope((void *)(drhd + 1),
((void *)drhd) +
drhd->header.length,
@@ -957,17 +959,18 @@ static void unmap_iommu(struct intel_iommu *iommu)
/**
* map_iommu: map the iommu's registers
* @iommu: the iommu to map
- * @phys_addr: the physical address of the base resgister
+ * @drhd: DMA remapping hardware definition structure
*
* Memory map the iommu's registers. Start w/ a single page, and
* possibly expand if that turns out to be insufficent.
*/
-static int map_iommu(struct intel_iommu *iommu, u64 phys_addr)
+static int map_iommu(struct intel_iommu *iommu, struct dmar_drhd_unit *drhd)
{
+ u64 phys_addr = drhd->reg_base_addr;
int map_size, err=0;
iommu->reg_phys = phys_addr;
- iommu->reg_size = VTD_PAGE_SIZE;
+ iommu->reg_size = drhd->reg_size;
if (!request_mem_region(iommu->reg_phys, iommu->reg_size, iommu->name))
{
pr_err("Can't reserve memory\n");
@@ -1051,7 +1054,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
}
sprintf(iommu->name, "dmar%d", iommu->seq_id);
- err = map_iommu(iommu, drhd->reg_base_addr);
+ err = map_iommu(iommu, drhd);
if (err) {
pr_err("Failed to map %s\n", iommu->name);
goto error_free_seq_id;
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 15c78678c5d3..c5deb47ecee1 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -655,7 +655,7 @@ struct acpi_dmar_pci_path {
struct acpi_dmar_hardware_unit {
struct acpi_dmar_header header;
u8 flags;
- u8 reserved;
+ u8 size;/* Size of the register set */
u16 segment;
u64 address;/* Register Base Address */
};
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index d81a51978d01..725d5e6acec0 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -39,6 +39,7 @@ struct dmar_drhd_unit {
struct list_head list; /* list of drhd units */
struct acpi_dmar_header *hdr; /* ACPI header */
u64 reg_base_addr; /* register base address*/
+ unsigned long reg_size; /* size of register set */
struct dmar_dev_scope *devices;/* target device array */
int devices_cnt;/* target device count */
u16 segment;/* PCI domain */
--
2.43.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13860):
https://lists.yoctoproject.org/g/linux-yocto/message/13860
Mute This Topic: https://lists.yoctoproject.org/mt/105704896/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] Seeking information on use of linux-yocto-dev
On Tue, Apr 23, 2024 at 12:34 PM Sourabh Banerjee (QUIC) <
quic_sbane...@quicinc.com> wrote:
>
>
> > -Original Message-
> > From: Bruce Ashfield
> > Sent: Tuesday, April 23, 2024 7:22 AM
> > To: Sourabh Banerjee (QUIC)
> > Cc: linux-yocto@lists.yoctoproject.org
> > Subject: Re: [linux-yocto] Seeking information on use of linux-yocto-dev
> >
> >
> > On Mon, Apr 22, 2024 at 4:29 PM quic_sbanerje via
> http://lists.yoctoproject.org
> > mailto:quicinc@lists.yoctoproject.org> wrote:
> > From a previous discussion with Richard, I understand, that the
> linux-yocto-dev
> > recipe exists for anyone needing more recent kernels. Bruce is
> maintaining is
> > as a rolling update, and version upgrades are quite frequent.
> >
> > I am seeking information on following to understand use of
> linux-yocto-dev
> > better:
> > 1. When there's a version bump for linux-yocto-dev is there a test suite
> that is
> > run?
> >
> > I have some simple scripts and manual tests that I run against each bump
> of -
> > dev.
> >
> > In particular core-image-kernel-dev and the tightly coupled tools (lttng,
> > systemtap, etc).
> >
> > A boot of systemd based images tends to shake out most of the major
> issues, so
> > that
> > is what I do.
>
> Thank you for pointing to core-image-kernel-dev.
> When building this image do you generally use poky-altcfg, as it includes
> systemd?
>
>
I have my own distro and configuration that I use. But I also do test with
poky and poky-altcfg.
> How is the decision made to create a linux-yocto_${version} recipe from
> linux-yocto-dev recipe? Is it guided by a set cadence?
>
It follows guidance we put together about 10 years ago now, it is somewhere
on the project wiki. I've also covered it in several presentations over the
past
few years as well.
But generally speaking on our non-LTS releases, it is three kernel versions
the latest lts, the latest released kernel around the -m3 timeframe and the
-dev kernel. For our LTS releases, we drop the "latest released" kernel, and
just do lts + dev.
>
> >
> > 2. Is linux-yocto-dev tested by the autobuilder or a similar CI?
> >
> > We've had adding it to the autobuilder CI on the wishlist for quite a
> while. I
> > thought
> > Ross added something a few months ago, but I can't recall the details.
> We do
> > need
> > to decide on exactly what to test, making sure it is lighter than what
> is run
> > against
> > the release kernels that I generate.
> >
> > If it was in CI there might be some breakage due to the bleeding edge
> nature of
> > the updates. We just wouldn't want it to block any project milestones if
> run as
> > part of CI.
> >
>
> Added Ross to get a bit more clarity on autobuilder setup to
> linux-yocto-dev.
>
> >
> > 3. Do BSP layer maintainers generally use linux-yocto-dev to verify the
> BSP layer
> > against kernel upstream?
> >
> > There are some developers that do that, yes. Others use it for the
> AUTOREV
> > and rolling nature of it, etc. Now that even linux-yocto-dev uses
> versioned
> > branches, we could in theory just use linux-yocto for all of those
> purposes, but
> > I still strongly prefer that only our supported versions appear in
> linux-yocto.
> >
> If a BSP maintainer chooses to use linux-yocto-dev and expands the test
> scope
> to frameworks such as Weston, pulseaudio etc., let's say while testing
> detects
> bugs what should be the next step?
>
If the bug is in the kernel, hopefully they'll take it to lkml, since
that's why we
have the -dev kernel tracking the latest. It makes upstream discussions
easier
and more relevant. If it is an issue with the -dev kernel and the rest of OE
core interacting in an unexpected way, then the linux-yocto or oe-core
mailing
lists are used to discuss.
Since -dev kernels are highlighting issues that we will eventually have in a
release, the issues are valid and treat them as such
Bruce
> I am trying to understand can a BSP maintainer use this as a reference to
> test
> and plan ahead.
>
> > Bruce
> >
> >
> >
> >
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at
> > its end
> > - "Use the force Harry" - Gandalf, Star Trek II
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13859):
https://lists.yoctoproject.org/g/linux-yocto/message/13859
Mute This Topic: https://lists.yoctoproject.org/mt/105677861/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] Seeking information on use of linux-yocto-dev
> -Original Message-
> From: Bruce Ashfield
> Sent: Tuesday, April 23, 2024 7:22 AM
> To: Sourabh Banerjee (QUIC)
> Cc: linux-yocto@lists.yoctoproject.org
> Subject: Re: [linux-yocto] Seeking information on use of linux-yocto-dev
>
>
> On Mon, Apr 22, 2024 at 4:29 PM quic_sbanerje via
> http://lists.yoctoproject.org
> mailto:quicinc@lists.yoctoproject.org> wrote:
> From a previous discussion with Richard, I understand, that the
> linux-yocto-dev
> recipe exists for anyone needing more recent kernels. Bruce is maintaining is
> as a rolling update, and version upgrades are quite frequent.
>
> I am seeking information on following to understand use of linux-yocto-dev
> better:
> 1. When there's a version bump for linux-yocto-dev is there a test suite that
> is
> run?
>
> I have some simple scripts and manual tests that I run against each bump of -
> dev.
>
> In particular core-image-kernel-dev and the tightly coupled tools (lttng,
> systemtap, etc).
>
> A boot of systemd based images tends to shake out most of the major issues, so
> that
> is what I do.
Thank you for pointing to core-image-kernel-dev.
When building this image do you generally use poky-altcfg, as it includes
systemd?
How is the decision made to create a linux-yocto_${version} recipe from
linux-yocto-dev recipe? Is it guided by a set cadence?
>
> 2. Is linux-yocto-dev tested by the autobuilder or a similar CI?
>
> We've had adding it to the autobuilder CI on the wishlist for quite a while. I
> thought
> Ross added something a few months ago, but I can't recall the details. We do
> need
> to decide on exactly what to test, making sure it is lighter than what is run
> against
> the release kernels that I generate.
>
> If it was in CI there might be some breakage due to the bleeding edge nature
> of
> the updates. We just wouldn't want it to block any project milestones if run
> as
> part of CI.
>
Added Ross to get a bit more clarity on autobuilder setup to linux-yocto-dev.
>
> 3. Do BSP layer maintainers generally use linux-yocto-dev to verify the BSP
> layer
> against kernel upstream?
>
> There are some developers that do that, yes. Others use it for the AUTOREV
> and rolling nature of it, etc. Now that even linux-yocto-dev uses versioned
> branches, we could in theory just use linux-yocto for all of those purposes,
> but
> I still strongly prefer that only our supported versions appear in
> linux-yocto.
>
If a BSP maintainer chooses to use linux-yocto-dev and expands the test scope
to frameworks such as Weston, pulseaudio etc., let's say while testing detects
bugs what should be the next step?
I am trying to understand can a BSP maintainer use this as a reference to test
and plan ahead.
> Bruce
>
>
>
>
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at
> its end
> - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13858):
https://lists.yoctoproject.org/g/linux-yocto/message/13858
Mute This Topic: https://lists.yoctoproject.org/mt/105677861/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.15 0/1] backport of TCP fix for CVE-2022-3566
From: Paul Gortmaker Mainline commit f49cd2f4d6 is listed as the fix for CVE-2022-3566. I guess the linux-stable team skipped over it since it didn't apply? Maybe enough other stuff has since been backported such that it does apply now - hands free with "wiggle" (the original AI if you ask me). Build and boot tested on v5.15/standard/base - ssh'd in and nothing to see in dmesg - nice and clean. It is already present in v6.1+ so nothing for us to do there. No rush on this - it has been hanging around since 2022! Paul. -- Kuniyuki Iwashima (1): tcp: Fix data races around icsk->icsk_af_ops. net/ipv4/tcp.c | 10 ++ net/ipv6/ipv6_sockglue.c | 3 ++- net/ipv6/tcp_ipv6.c | 6 -- 3 files changed, 12 insertions(+), 7 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13856): https://lists.yoctoproject.org/g/linux-yocto/message/13856 Mute This Topic: https://lists.yoctoproject.org/mt/105689820/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH 1/1] tcp: Fix data races around icsk->icsk_af_ops.
From: Kuniyuki Iwashima
commit f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57 upstream.
setsockopt(IPV6_ADDRFORM) and tcp_v6_connect() change icsk->icsk_af_ops
under lock_sock(), but tcp_(get|set)sockopt() read it locklessly. To
avoid load/store tearing, we need to add READ_ONCE() and WRITE_ONCE()
for the reads and writes.
Thanks to Eric Dumazet for providing the syzbot report:
BUG: KCSAN: data-race in tcp_setsockopt / tcp_v6_connect
write to 0x88813c624518 of 8 bytes by task 23936 on cpu 0:
tcp_v6_connect+0x5b3/0xce0 net/ipv6/tcp_ipv6.c:240
__inet_stream_connect+0x159/0x6d0 net/ipv4/af_inet.c:660
inet_stream_connect+0x44/0x70 net/ipv4/af_inet.c:724
__sys_connect_file net/socket.c:1976 [inline]
__sys_connect+0x197/0x1b0 net/socket.c:1993
__do_sys_connect net/socket.c:2003 [inline]
__se_sys_connect net/socket.c:2000 [inline]
__x64_sys_connect+0x3d/0x50 net/socket.c:2000
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0x88813c624518 of 8 bytes by task 23937 on cpu 1:
tcp_setsockopt+0x147/0x1c80 net/ipv4/tcp.c:3789
sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3585
__sys_setsockopt+0x212/0x2b0 net/socket.c:2252
__do_sys_setsockopt net/socket.c:2263 [inline]
__se_sys_setsockopt net/socket.c:2260 [inline]
__x64_sys_setsockopt+0x62/0x70 net/socket.c:2260
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x8539af68 -> 0x8539aff8
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 23937 Comm: syz-executor.5 Not tainted
6.0.0-rc4-syzkaller-00331-g4ed9c1e971b1-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 08/26/2022
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot
Reported-by: Eric Dumazet
Signed-off-by: Kuniyuki Iwashima
Signed-off-by: Jakub Kicinski
Signed-off-by: Paul Gortmaker
---
net/ipv4/tcp.c | 10 ++
net/ipv6/ipv6_sockglue.c | 3 ++-
net/ipv6/tcp_ipv6.c | 6 --
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 16fd3da68e9f6..17033e0cfecb7 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3704,8 +3704,9 @@ int tcp_setsockopt(struct sock *sk, int level, int
optname, sockptr_t optval,
const struct inet_connection_sock *icsk = inet_csk(sk);
if (level != SOL_TCP)
- return icsk->icsk_af_ops->setsockopt(sk, level, optname,
-optval, optlen);
+ /* Paired with WRITE_ONCE() in do_ipv6_setsockopt() and
tcp_v6_connect() */
+ return READ_ONCE(icsk->icsk_af_ops)->setsockopt(sk, level,
optname,
+ optval, optlen);
return do_tcp_setsockopt(sk, level, optname, optval, optlen);
}
EXPORT_SYMBOL(tcp_setsockopt);
@@ -4303,8 +4304,9 @@ int tcp_getsockopt(struct sock *sk, int level, int
optname, char __user *optval,
struct inet_connection_sock *icsk = inet_csk(sk);
if (level != SOL_TCP)
- return icsk->icsk_af_ops->getsockopt(sk, level, optname,
-optval, optlen);
+ /* Paired with WRITE_ONCE() in do_ipv6_setsockopt() and
tcp_v6_connect() */
+ return READ_ONCE(icsk->icsk_af_ops)->getsockopt(sk, level,
optname,
+ optval, optlen);
return do_tcp_getsockopt(sk, level, optname, optval, optlen);
}
EXPORT_SYMBOL(tcp_getsockopt);
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 197e12d5607f1..faf9ec9355d9a 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -476,7 +476,8 @@ static int do_ipv6_setsockopt(struct sock *sk, int level,
int optname,
sock_prot_inuse_add(net, _prot, 1);
local_bh_enable();
sk->sk_prot = _prot;
- icsk->icsk_af_ops = _specific;
+ /* Paired with READ_ONCE() in
tcp_(get|set)sockopt() */
+ WRITE_ONCE(icsk->icsk_af_ops, _specific);
sk->sk_socket->ops = _stream_ops;
sk->sk_family = PF_INET;
tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index c18fdddbfa09d..29c8d386274bf 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -237,7 +237,8 @@ static int tcp_v6_connect(struct sock *sk, struct sockaddr
*uaddr,
sin.sin_port = usin->sin6_port;
sin.sin_addr.s_addr = usin->sin6_addr.s6_addr32[3];
- icsk->icsk_af_ops = _mapped;
+ /* Paired
