This reverts commit 1a291b98a3.
It was perserving the ABI, but that is not needed anymore at this point
in time.
Change-Id: I53ec3c627f1a697a1d2054f85e9d794e6e18df37
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit b5a444808a.
It was perserving the ABI, but that is not needed anymore at this point
in time.
Change-Id: I595ea6488d44620f3576e4c9ecf5dc7e4d269909
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit e0f8567110.
It was perserving the ABI, but that is not needed anymore at this point
in time.
Change-Id: I4f91f78a34c8ab5761d85ebb4061f9620eec592a
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 77bcc673f6.
It was perserving the ABI, but that is not needed anymore at this point
in time.
Change-Id: I0737d8ce7f08323128fa61389169e5e692b56351
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 1e993e7647.
It was perserving the ABI, but that is not needed anymore at this point
in time.
Change-Id: I7b6c62480765cfa9751874641092b2a52229ea84
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit f12f3bc9c7.
It was perserving the ABI, but that is not needed anymore at this point
in time.
Change-Id: Idfe61bf8ce3a83c66c31769b845572454f0f196b
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 8ec4245b45.
It was perserving the ABI, but that is not needed anymore at this point
in time.
Change-Id: I82776674a83f38800e3144d025631e4256cc53f4
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 2b47e2bee0.
It was perserving the ABI, but that is not needed anymore at this point
in time.
Change-Id: I7efd4dd7abde9f5baa37cb3731aa40b7ff94d2bb
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit e7db10fe57.
It was perserving the ABI, but that is not needed anymore at this point
in time.
Change-Id: Ifc79e504dbf17466a88ac76162ed77dcb5c13d19
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Recall that the per-node memcg LRU has two generations and they alternate
when the last memcg (of a given node) is moved from one to the other.
Each generation is also sharded into multiple bins to improve scalability.
A reclaimer starts with a random bin (in the old generation) and, if it
fails, it will retry, i.e., to try the rest of the bins.
If a reclaimer fails with the last memcg, it should move this memcg to the
young generation first, which causes the generations to alternate, and
then retry. Otherwise, the retries will be futile because all other bins
are empty.
Link: https://lkml.kernel.org/r/20230213075322.1416966-1-yuzhao@google.com
Fixes: e4dde56cd2 ("mm: multi-gen LRU: per-node lru_gen_folio lists")
Signed-off-by: Yu Zhao <yuzhao@google.com>
Reported-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 274865848
(cherry picked from commit 9f550d78b4)
Change-Id: Ie92535676b005ec9e7987632b742fdde8d54436f
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Among the flags in scan_control:
1. sc->may_swap, which indicates swap constraint due to memsw.max, is
supported as usual.
2. sc->proactive, which indicates reclaim by memory.reclaim, may not
opportunistically skip the aging path, since it is considered less
latency sensitive.
3. !(sc->gfp_mask & __GFP_IO), which indicates IO constraint, lowers
swappiness to prioritize file LRU, since clean file folios are more
likely to exist.
4. sc->may_writepage and sc->may_unmap, which indicates opportunistic
reclaim, are rejected, since unmapped clean folios are already
prioritized. Scanning for more of them is likely futile and can
cause high reclaim latency when there is a large number of memcgs.
The rest are handled by the existing code.
Link: https://lkml.kernel.org/r/20221222041905.2431096-8-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Michael Larabel <Michael@MichaelLarabel.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 274865848
(cherry picked from commit e9d4e1ee78)
[TJ: Resolved conflict with older function signature for min_cgroup_below_min, and over
cdded86118 ("ANDROID: MGLRU: Don't skip anon reclaim if swap low")]
Change-Id: Ic2e779eaf4e91a3921831b4e2fa10c740dc59d50
Signed-off-by: T.J. Mercier <tjmercier@google.com>
For each node, memcgs are divided into two generations: the old and
the young. For each generation, memcgs are randomly sharded into
multiple bins to improve scalability. For each bin, an RCU hlist_nulls
is virtually divided into three segments: the head, the tail and the
default.
An onlining memcg is added to the tail of a random bin in the old
generation. The eviction starts at the head of a random bin in the old
generation. The per-node memcg generation counter, whose reminder (mod
2) indexes the old generation, is incremented when all its bins become
empty.
There are four operations:
1. MEMCG_LRU_HEAD, which moves an memcg to the head of a random bin in
its current generation (old or young) and updates its "seg" to
"head";
2. MEMCG_LRU_TAIL, which moves an memcg to the tail of a random bin in
its current generation (old or young) and updates its "seg" to
"tail";
3. MEMCG_LRU_OLD, which moves an memcg to the head of a random bin in
the old generation, updates its "gen" to "old" and resets its "seg"
to "default";
4. MEMCG_LRU_YOUNG, which moves an memcg to the tail of a random bin
in the young generation, updates its "gen" to "young" and resets
its "seg" to "default".
The events that trigger the above operations are:
1. Exceeding the soft limit, which triggers MEMCG_LRU_HEAD;
2. The first attempt to reclaim an memcg below low, which triggers
MEMCG_LRU_TAIL;
3. The first attempt to reclaim an memcg below reclaimable size
threshold, which triggers MEMCG_LRU_TAIL;
4. The second attempt to reclaim an memcg below reclaimable size
threshold, which triggers MEMCG_LRU_YOUNG;
5. Attempting to reclaim an memcg below min, which triggers
MEMCG_LRU_YOUNG;
6. Finishing the aging on the eviction path, which triggers
MEMCG_LRU_YOUNG;
7. Offlining an memcg, which triggers MEMCG_LRU_OLD.
Note that memcg LRU only applies to global reclaim, and the
round-robin incrementing of their max_seq counters ensures the
eventual fairness to all eligible memcgs. For memcg reclaim, it still
relies on mem_cgroup_iter().
Link: https://lkml.kernel.org/r/20221222041905.2431096-7-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Michael Larabel <Michael@MichaelLarabel.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 274865848
(cherry picked from commit e4dde56cd2)
[TJ: Resolved conflicts with older function signatures for
min_cgroup_below_min / min_cgroup_below_low and includes]
Change-Id: Idc8a0f635e035d72dd911f807d1224cb47cbd655
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Recall that the aging produces the youngest generation: first it scans
for accessed folios and updates their gen counters; then it increments
lrugen->max_seq.
The current aging fairness safeguard for kswapd uses two passes to
ensure the fairness to multiple eligible memcgs. On the first pass,
which is shared with the eviction, it checks whether all eligible
memcgs are low on cold folios. If so, it requires a second pass, on
which it ages all those memcgs at the same time.
With memcg LRU, the aging, while ensuring eventual fairness, will run
when necessary. Therefore the current aging fairness safeguard for
kswapd will not be needed.
Note that memcg LRU only applies to global reclaim. For memcg reclaim,
the aging can be unfair to different memcgs, i.e., their
lrugen->max_seq can be incremented at different paces.
Link: https://lkml.kernel.org/r/20221222041905.2431096-5-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Michael Larabel <Michael@MichaelLarabel.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 274865848
(cherry picked from commit 7348cc9182)
[TJ: Resolved conflicts with older function signatures for
min_cgroup_below_min / min_cgroup_below_low]
Change-Id: I6e36ecfbaaefbc0a56d9a9d5d7cbe404ed7f57a5
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Recall that the eviction consumes the oldest generation: first it
bucket-sorts folios whose gen counters were updated by the aging and
reclaims the rest; then it increments lrugen->min_seq.
The current eviction fairness safeguard for global reclaim has a
dilemma: when there are multiple eligible memcgs, should it continue
or stop upon meeting the reclaim goal? If it continues, it overshoots
and increases direct reclaim latency; if it stops, it loses fairness
between memcgs it has taken memory away from and those it has yet to.
With memcg LRU, the eviction, while ensuring eventual fairness, will
stop upon meeting its goal. Therefore the current eviction fairness
safeguard for global reclaim will not be needed.
Note that memcg LRU only applies to global reclaim. For memcg reclaim,
the eviction will continue, even if it is overshooting. This becomes
unconditional due to code simplification.
Link: https://lkml.kernel.org/r/20221222041905.2431096-4-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Michael Larabel <Michael@MichaelLarabel.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 274865848
(cherry picked from commit a579086c99)
Change-Id: I08ac1b3c90e29cafd0566785aaa4bcdb5db7d22c
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Patch series "mm: multi-gen LRU: memcg LRU", v3.
Overview
========
An memcg LRU is a per-node LRU of memcgs. It is also an LRU of LRUs,
since each node and memcg combination has an LRU of folios (see
mem_cgroup_lruvec()).
Its goal is to improve the scalability of global reclaim, which is
critical to system-wide memory overcommit in data centers. Note that
memcg reclaim is currently out of scope.
Its memory bloat is a pointer to each lruvec and negligible to each
pglist_data. In terms of traversing memcgs during global reclaim, it
improves the best-case complexity from O(n) to O(1) and does not affect
the worst-case complexity O(n). Therefore, on average, it has a sublinear
complexity in contrast to the current linear complexity.
The basic structure of an memcg LRU can be understood by an analogy to
the active/inactive LRU (of folios):
1. It has the young and the old (generations), i.e., the counterparts
to the active and the inactive;
2. The increment of max_seq triggers promotion, i.e., the counterpart
to activation;
3. Other events trigger similar operations, e.g., offlining an memcg
triggers demotion, i.e., the counterpart to deactivation.
In terms of global reclaim, it has two distinct features:
1. Sharding, which allows each thread to start at a random memcg (in
the old generation) and improves parallelism;
2. Eventual fairness, which allows direct reclaim to bail out at will
and reduces latency without affecting fairness over some time.
The commit message in patch 6 details the workflow:
https://lore.kernel.org/r/20221222041905.2431096-7-yuzhao@google.com/
The following is a simple test to quickly verify its effectiveness.
Test design:
1. Create multiple memcgs.
2. Each memcg contains a job (fio).
3. All jobs access the same amount of memory randomly.
4. The system does not experience global memory pressure.
5. Periodically write to the root memory.reclaim.
Desired outcome:
1. All memcgs have similar pgsteal counts, i.e., stddev(pgsteal)
over mean(pgsteal) is close to 0%.
2. The total pgsteal is close to the total requested through
memory.reclaim, i.e., sum(pgsteal) over sum(requested) is close
to 100%.
Actual outcome [1]:
MGLRU off MGLRU on
stddev(pgsteal) / mean(pgsteal) 75% 20%
sum(pgsteal) / sum(requested) 425% 95%
####################################################################
MEMCGS=128
for ((memcg = 0; memcg < $MEMCGS; memcg++)); do
mkdir /sys/fs/cgroup/memcg$memcg
done
start() {
echo $BASHPID > /sys/fs/cgroup/memcg$memcg/cgroup.procs
fio -name=memcg$memcg --numjobs=1 --ioengine=mmap \
--filename=/dev/zero --size=1920M --rw=randrw \
--rate=64m,64m --random_distribution=random \
--fadvise_hint=0 --time_based --runtime=10h \
--group_reporting --minimal
}
for ((memcg = 0; memcg < $MEMCGS; memcg++)); do
start &
done
sleep 600
for ((i = 0; i < 600; i++)); do
echo 256m >/sys/fs/cgroup/memory.reclaim
sleep 6
done
for ((memcg = 0; memcg < $MEMCGS; memcg++)); do
grep "pgsteal " /sys/fs/cgroup/memcg$memcg/memory.stat
done
####################################################################
[1]: This was obtained from running the above script (touches less
than 256GB memory) on an EPYC 7B13 with 512GB DRAM for over an
hour.
This patch (of 8):
The new name lru_gen_folio will be more distinct from the coming
lru_gen_memcg.
Link: https://lkml.kernel.org/r/20221222041905.2431096-1-yuzhao@google.com
Link: https://lkml.kernel.org/r/20221222041905.2431096-2-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Michael Larabel <Michael@MichaelLarabel.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 274865848
(cherry picked from commit 391655fe08)
Change-Id: I7df67e0e2435ba28f10eaa57d28d98b61a9210a6
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Users of dmabuf_page_pool should not need to refer to its fields, so
hide them from the KMI. Add dmabuf_page_pool_get_size to fullfill the
needs of users.
Bug: 264474028
Change-Id: I848ff52e73a13568f561deeb6aea48f40dc0960b
Signed-off-by: T.J. Mercier <tjmercier@google.com>
kmap_atomic was deprecated in 5.11, and checkpatch now warns about use
of it. Replace with kmap_local_page, and do not manually disable
preemption or page faults.
Bug: 264474028
Fixes: 818b4f6bb8b8 ("ANDROID: dma-buf: system_heap: Add pagepool support to system heap")
Change-Id: Idd6413ff56aadf4fd925acb6f567366d0e03166f
Signed-off-by: T.J. Mercier <tjmercier@google.com>
We should use spinlock to protect page pool's critical section as
1. The critical section is short, using spinlock is more efficient.
2. Spinlock could protect priority inversion. Ex. Low priority
thread (dmabuf-deferred) hold the page lock but get scheduled
out under heavy loading. Then the other high priority threads
need to wait for dmabuf-deferred to release the lock. It causes
long allocation latency and possible UI jank.
Also, we could move NR_KERNEL_MISC_RECLAIMABLE stat out of the
critical section to make it shorter as mod_node_page_state can
handle concurrent access cases.
Bug: 245454030
Change-Id: I15f349f9e893621f71ca79f1de037de184c33edf
Signed-off-by: Martin Liu <liumartin@google.com>
dmabuf_page_pool_init_shrinker needs to be static to prevent a warning
when compiling with -Wmissing-prototypes. Change it to be static.
Fixes: e7dac4c323 ("ANDROID: dma-buf: heaps: Add a shrinker controlled page pool")
Bug: 168742043
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I64184cf4062e33c14a60b9c3d505db922f2b9c0b
Since vendors might depend on them for their system heap
implementations, make the page-pool library built-in to
freeze its KMI.
Bug: 183902174
Bug: 212210831
Change-Id: If633619ec1f78d0fbd73c43c48b19d98db7807af
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Wi-Fi Aware R4 specification defines NAN Pairing which uses PASN handshake
to authenticate the peer and generate keys. Hence allow to register and transmit
the PASN authentication frames on NAN interface and set the keys to driver or
underlying modules on NAN interface.
The driver needs to configure the feature flag NL80211_EXT_FEATURE_SECURE_NAN,
which also helps userspace modules to know if the driver supports secure NAN.
Signed-off-by: Vinay Gannevaram <quic_vganneva@quicinc.com>
Link: https://lore.kernel.org/r/1675519179-24174-1-git-send-email-quic_vganneva@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: Ib8e15683772cf9696b51fb5360642813ca0a078b
(cherry picked from commit 9b89495e47)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Currently action frames TX only with ML address as A3(BSSID) are
allowed in an ML AP, but TX for a non-ML Station can happen in any
link of an ML BSS with link BSS address as A3.
In case of an MLD, if User-space has provided a valid link_id in
action frame TX request, allow transmission of the frame in that link.
Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com>
Link: https://lore.kernel.org/r/20230201061602.3918-1-quic_ramess@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: Iceb00b0713d9123f040e10e06cbfc412ee6a0375
(cherry picked from commit 19085ef39f)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
- New feature flag, NL80211_EXT_FEATURE_PUNCT, to advertise
driver support for preamble puncturing in AP mode.
- New attribute, NL80211_ATTR_PUNCT_BITMAP, to receive a puncturing
bitmap from the userspace during AP bring up (NL80211_CMD_START_AP)
and channel switch (NL80211_CMD_CHANNEL_SWITCH) operations. Each bit
corresponds to a 20 MHz channel in the operating bandwidth, lowest
bit for the lowest channel. Bit set to 1 indicates that the channel
is punctured. Higher 16 bits are reserved.
- New members added to structures cfg80211_ap_settings and
cfg80211_csa_settings to propagate the bitmap to the driver after
validation.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Signed-off-by: Muna Sinada <quic_msinada@quicinc.com>
Link: https://lore.kernel.org/r/20230131001227.25014-3-quic_alokad@quicinc.com
[move validation against 0xffff into policy]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: I2d9a90cba8812bfe81d0168133ef2239dcc536ac
(cherry picked from commit d7c1a9a0ed)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
- Move ieee80211_valid_disable_subchannel_bitmap() from mlme.c to
chan.c, rename it as cfg80211_valid_disable_subchannel_bitmap()
and export it.
- Modify the prototype to include struct cfg80211_chan_def instead
of only bandwidth to support a check which returns false if the
primary channel is punctured.
Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Link: https://lore.kernel.org/r/20230131001227.25014-2-quic_alokad@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: I31864e26bccd106c0bedbdd9709c8679643aeafb
(cherry picked from commit b25413fed3)
[shivbara: Skipped the changes in net/mac80211/mlme.c due to missing dependency
changes]
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
nl80211_send_ap_stopped() can be called multiple times on the same
netdev for each link when using Multi-Link Operation. Add the
MLO_LINK_ID attribute to the event to allow userspace to distinguish
which link the event is for.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Link: https://lore.kernel.org/r/20230128125844.2407135-2-alvin@pqrs.dk
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: I02104259eda61893f5f40bcd18a5e89bf6871ae6
(cherry picked from commit cba7217a92)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Add support to offload OWE processing to user space for MLD AP when
driver's SME in use.
Add new parameters in struct cfg80211_update_owe_info to provide below
information in cfg80211_update_owe_info_event() call:
- MLO link ID of the AP, with which station requested (re)association.
This is applicable for both MLO and non-MLO station connections when
the AP affiliated with an MLD.
- Station's MLD address if the connection is MLO capable.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20230126143256.960563-3-quic_vjakkam@quicinc.com
[reformat the trace event macro]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: Ifba181b7eb0912c318f3f3967b29e1e94a7c751d
(cherry picked from commit 8bb588d975)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Add support for drivers to indicate STA connection(MLO/non-MLO) when
user space SME (e.g., hostapd) is not used for MLD AP.
Add new parameters in struct station_info to provide below information
in cfg80211_new_sta() call:
- MLO link ID of the AP, with which station completed (re)association.
This is applicable for both MLO and non-MLO station connections when
the AP affiliated with an MLD.
- Station's MLD address if the connection is MLO capable.
- (Re)Association Response IEs sent to the station. User space needs
this to determine rejected and accepted affiliated links information
of the connected station if the connection is MLO capable.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20230126143256.960563-2-quic_vjakkam@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: I3b0e68d8e328054e4fe6c9bee9bb3083f87744ec
(cherry picked from commit a42e59eb96)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
Currently authentication request event interface doesn't have support to
indicate the user space whether it should enable MLO or not during the
authentication with the specified AP. But driver needs such capability
since the connection is MLO or not decided by the driver in case of SME
offload to the driver.
Add support for driver to indicate MLD address of the AP in
authentication offload request to inform user space to enable MLO during
authentication process. Driver shall look at NL80211_ATTR_MLO_SUPPORT
flag capability in NL80211_CMD_CONNECT to know whether the user space
supports enabling MLO during the authentication offload.
User space should enable MLO during the authentication only when it
receives the AP MLD address in authentication offload request. User
space shouldn't enable MLO if the authentication offload request doesn't
indicate the AP MLD address even if the AP is MLO capable.
When MLO is enabled, user space should use the MAC address of the
interface (on which driver sent request) as self MLD address. User space
and driver to use MLD addresses in RA, TA and BSSID fields of the frames
between them, and driver translates the MLD addresses to/from link
addresses based on the link chosen for the authentication.
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/20230116125058.1604843-1-quic_vjakkam@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: I0a1450c6bb1c0d8d797c43eac2cab9637f0f0bec
(cherry picked from commit 9a47c1ef5a)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
With %pM, this really is no longer needed, and actually
longer to spell out. Remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: I817fb4c15780ea559d7d5d9ccc448d008f1d7122
(cherry picked from commit 3d9c361713)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
In case of 4way handshake offload, transition disable policy
updated by the AP during EAPOL 3/4 is not updated to the upper layer.
This results in mismatch between transition disable policy
between the upper layer and the driver. This patch addresses this
issue by updating transition disable policy as part of port
authorization indication.
Signed-off-by: Vinayak Yadawad <vinayak.yadawad@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: Iac5d22a2c3999c7bdddc3a1f683fef82ed8ff918
(cherry picked from commit 0ff57171d6)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
We clearly need the link ID here, to know the right BSS
to configure. Use/require it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: I071708c1f521ee6f930472a60d5ee5d6aca43d72
(cherry picked from commit 1e0f8cc96b)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
For assoc and connect result APIs, support reporting
failed links; they should still come with the BSS
pointer in the case of assoc, so they're released
correctly. In the case of connect result, this is
optional.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 271996243
Change-Id: Ibd996c8807ad118787911fd8fe4dc2098d9c75e9
(cherry picked from commit 53ad07e982)
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
The GKI policy allows the addition of new symbols to a frozen KMI as
long as doing so has no impact on existing frozen symbols. Interestingly
the hypervisor's ABI is defined by the pkvm_module_ops structure. Any
addition to this struct will be flagged as a type change, which equates
to a KMI breakage in the GKI world. This could become a major problem
long term if it prevented backport of (security) fixes to KMI-frozen
kernels.
To allow such backports, add a set of reserved ABI slots to the
pkvm_module_ops struct. These slots are usually reserved to fix LTS
merges, but given that none of the pKVM module code is upstream yet,
these slots are likely to be used by Android-specific fixes.
Bug: 233587962
Change-Id: I61a00a09947ccff153c96a4829e083ef9ede19d3
Signed-off-by: Quentin Perret <qperret@google.com>
pKVM modules may need to access memory that is kept map in the host's
stage-2 page-table. Expose the host_{un}share_hyp() API to allow the
use-case, as well as the pinning API that goes with it.
Bug: 245034629
Change-Id: I1b5abacfcd2f066b1cbb1bbac43b77e6808f559c
Signed-off-by: Quentin Perret <qperret@google.com>
DWARFv5 is the latest iteration of the debug info spec; it contains many
encoding tricks to optimize for space.
For example, with this patch applied (DWARFv5), for
build.config.gki.aarch64:
$ du -h out/android-mainline/dist/vmlinux
304M out/android-mainline/dist/vmlinux
Before (DWARFv4):
du -h out/android-mainline/dist/vmlinux
339M out/android-mainline/dist/vmlinux
Bug: 192694378
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: I6644482d9b12eb3e0d1d3676c53ee2eee97a6573
ABI is being implemented for x86_64, making it necessary
to support protected exports header file generation for
the GKI modules for multiple architecture.
Enable support to select required inputs based on the ARCH
to generate gki_module_protected_exports.h during kernel
build.
Inputs for generating gki_module_protected_exports.h are:
ARCH = arm64:
ABI Protected exports list: abi_gki_protected_exports_aarch64
Protected GKI modules list: gki_aarch64_protected_modules
ARCH = x86_64:
ABI Protected exports list: abi_gki_protected_exports_x86_64
Protected GKI modules list: gki_x86_64_protected_modules
Test: TH
Test: Manual verification of the generated header file
Test: bazel run //common:kernel_aarch64_abi_update_protected_exports
Bug: 151893768
Change-Id: Ic4bcb2732199b71a7973b5ce4c852bcd95d37131
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
