This reverts commit bc84b4adb1469e3d05ad76c304a4c545feaf1f88.
Bug: 22846070
Change-Id: Ib4cb130b2225ea2e22556ff852313e0de7dddcab
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
This reverts commit c9a8571249fa3a55a0490bd571eaf0cea097fab0.
Bug: 22846070
Change-Id: I85e2b6322f98bd584ed523b0bd0291375dbc35dc
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
This reverts commit c06168226f5eaaaad93af5b2811f213b01382363.
Bug: 22846070
Change-Id: I665c1f2350e10ce890e7c4be1a06e666929d5d7a
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
The idea is simple. We need to get the siginfo for each signal on
checkpointing dump, and then return it back on restore.
The first problem is that the kernel doesn't report complete siginfos to
userspace. In a signal handler the kernel strips SI_CODE from siginfo.
When a siginfo is received from signalfd, it has a different format with
fixed sizes of fields. The interface of signalfd was extended. If a
signalfd is created with the flag SFD_RAW, it returns siginfo in a raw
format.
rt_sigqueueinfo looks suitable for restoring signals, but it can't send
siginfo with a positive si_code, because these codes are reserved for
the kernel. In the real world each person has right to do anything with
himself, so I think a process should able to send any siginfo to itself.
This patch:
The kernel prevents sending of siginfo with positive si_code, because
these codes are reserved for kernel. I think we can allow a task to
send such a siginfo to itself. This operation should not be dangerous.
This functionality is required for restoring signals in
checkpoint/restart.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: Ibdd8af9dc6400f42db1e3200db90f36df4fe9cc4
(cherry picked from commit 66dd34ad31e5963d72a700ec3f2449291d322921)
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
* Disable CONFIG_USB_ANDROID_SAMSUNG_MTP to allow MTP to work
* Enable CONFIG_CRYPTO_DEV_QCEDEV
Change-Id: I00d82d5ae90fcd4eb95f976728dc83d16947aec0
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Alex Efros reported rpfilter module doesn't match following packets:
IN=br.qemu SRC=192.168.2.1 DST=192.168.2.255 [ .. ]
(netfilter bugzilla #814).
Problem is that network stack arranges for the locally generated broadcasts
to appear on the interface they were sent out, so the IFF_LOOPBACK check
doesn't trigger.
As -m rpfilter is restricted to PREROUTING, we can check for existing
rtable instead, it catches locally-generated broad/multicast case, too.
Change-Id: I2d921ac4d53e5b1ca9a5249e489c33e4fa4a4b3a
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
bc is the standard tool for multi-precision arithmetic. We switched
to Perl because akpm reported a hard-to-reproduce build hang, which
was very odd because affected and unaffected machines were all running
the same version of GNU bc.
Unfortunately switching to Perl required a really ugly "canning"
mechanism to support Perl < 5.8 installations lacking the Math::BigInt
module.
It was recently pointed out to me that some very old versions of GNU
make had problems with pipes in subshells, which was indeed the
construct used in the Makefile rules in that version of the patch;
Perl didn't need it so switching to Perl fixed the problem for
unrelated reasons. With the problem (hopefully) root-caused, we can
switch back to bc and do the arbitrary-precision arithmetic naturally.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change-Id: I8450a919c2d27b6c18561621c0a48a762e46a22d
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Code clean-ups & vibration strength over stock 126 value
Signed-off-by: Jean-Pierre Rasquin <yank555.lu@gmail.com>
Change-Id: Ie0941223f07a5df6baadad6b8228cc91710040c9
It has been observed that default values for some of key tcp/ip
parameters are affecting the tput/performance of the system. Hence
extending configuration capabilities to TCP/Ip stack through
sysctl interface
CRs-Fixed: 507581
Signed-off-by: Kiran Kumar Lokere <klokere@codeaurora.org>
Change-Id: Ia92fc229c0a4a8c3f7e4e02cf7e3c8849719ddff
There is no return statement in case of invalid sequence length in
__wlan_hdd_cfg80211_add_key api.
Return an error code in case of invalid seq_len.
Issue: SEC-1245
Change-Id: Ib240f6cf91d9d563dd87148c15e06ae8b48919d5
CRs-Fixed: 2153553
(adapted from commit https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/prima
5a0eeb72c3cde7dcb8096967561a88a678ad9aec)
propagation from qcacld-3.0 to prima
Currently the key sequence counter received from userspace is not
propagated to SME, so add logic to propagate it.
Issue: SEC-1245
Change-Id: I5371700003744eb967c578c44e4d130628efcdc8
CRs-Fixed: 2134583
(adapted from commit https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/prima
6a2b6756bad53d057cd3cb7856b9184d0011e1e0)
During initializing ibss security settings there is a possibility
of integer underflow while extracting wpa ie because of ie length
check miss.
Add wpa ie length boundary check before extracting wpa ie.
Issue: SEC-1249
Change-Id: I37d8ee5ea1e1ba12277128a1407783f5647251b6
CRs-Fixed: 2151241
(adapted from commit https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0
27381e9d253629180dcdaa698d3fd01bec28d351)
propagation from qcacld-3.0 to prima.
Currently sizeof(struct ieee80211_mgmt) + IE len is used to calculate
the total frame length to send the beacon/probe to kernel.
struct ieee80211_mgmt contains union to define different frames and
thus the sizeof(struct ieee80211_mgmt) may give extra length for
beacon/probe if any of the union size is greater than the probe/beacon
union size. This result in trail of zeroes at the end of the frame.
To fix this use sizeof(mgmt_mac_header) + SIR_MAC_B_PR_SSID_OFFSET +
ie len to determine the exact size of the frame.
Change-Id: I71e94b111f36fcd4060befcae282f1fcce5e17f1
CRs-Fixed: 2251716
Currently there are multiple cfg80211 vendor commands where MAC
address attributes are defined in a nla_policy table with a type of
NLA_UNSPEC but without a minimum length. Add the proper minimum length
to avoid buffer overread.
Change-Id: I11e1205943147102a536ca462fbdba7c826dd195
CRs-Fixed: 2061251
[GabrieleM: Partially applied with 3617aa44129c503af51f4f0537b9c6866]
Add changes to expose dump stack functionality which can be used
by driver to dump stack information when it requires
CR Fixed: 943322
Change-Id: I0fde7142dea2c18daf6b1fb0c5ee4bb8a31a6be0
Signed-off-by: Padma, Santhosh Kumar <skpadma@codeaurora.org>
Signed-off-by: Pradosh Das <prados@codeaurora.org>
Several build configurations had already disabled this warning because
it generates a lot of false positives. But some had not, and it was
still enabled for "allmodconfig" builds, for example.
Looking at the warnings produced, every single one I looked at was a
false positive, and the warnings are frequent enough (and big enough)
that they can easily hide real problems that you don't notice in the
noise generated by -Wmaybe-uninitialized.
The warning is good in theory, but this is a classic case of a warning
that causes more problems than the warning can solve.
If gcc gets better at avoiding false positives, we may be able to
re-enable this warning. But as is, we're better off without it, and I
want to be able to see the *real* warnings.
Change-Id: Ie810d255be8911c413c9abe6965a9a66639a1dce
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* The function prototype for this function has become :
int mdss_panel_dt_get_dst_fmt(u32 bpp, char mipi_mode, u32 pixel_packing,char *dst_format);
in the latest source drop
In this API, we were using sizeof operator for an array
given as function argument, which is invalid.
However this API is not used anywhere.
Change-Id: I80a43472b35f0f6c117624de2b2907b37eefb786
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>