Lineage 18.1 #16
Open
Lineage 18.1 #16
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Change-Id: I54c775bb80c2151bdc69ea9fb53a48a34327bbef
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Change-Id: Id57abf0a4bd0b433fecc622eecb383cd4ea29d17 Signed-off-by: Paul Keith <[email protected]>
Change-Id: I72ba7a14b56175535884390e8601960b5d8ed1cf Signed-off-by: Paul Keith <[email protected]>
* This is the proper thing to do for filesystem drivers Change-Id: I109b201d85e324cc0a72c3fcd09df4a3e1703042 Signed-off-by: Paul Keith <[email protected]>
* Update default charset for FAT to UTF-8, matching sdFAT's default.
resolves issues with tethering after november security update
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
Add support to early mount system partition so that system modules can be loaded during early init for msm8226 and msm8974. Change-Id: I9d75bec6ff9bada5ab2db6de2a58e40323aa6ca2
Change-Id: Ibbf1efd2aa19a2790773bd84da3364cfeffffe4b
* backported from s9 Change-Id: I48476e899495490ded64a9e173e3daa3c4cdafa0
Each zcomp backend uses own gfp flag but it's pointless because the context they could be called is driven by upper layer(ie, zcomp frontend). As well, zcomp frondend could call them in different context. One context(ie, zram init part) is it should be better to make sure successful allocation other context(ie, further stream allocation part for accelarating I/O speed) is just optional so let's pass gfp down from driver (ie, zcomp frontend) like normal MM convention. [[email protected]: add missing __vmalloc zero and highmem gfps] Signed-off-by: Minchan Kim <[email protected]> Signed-off-by: Sergey Senozhatsky <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit 75d8947a36d0c9aedd69118d1f14bf424005c7c2) Signed-off-by: Peter Kalauskas <[email protected]> Bug: 112488418 Change-Id: I572d0565de5aff94ebe0782eba9d34f9c9862060
Do not __GFP_ZERO allocated zcomp ->private pages. We keep allocated streams around and use them for read/write requests, so we supply a zeroed out ->private to compression algorithm as a scratch buffer only once -- the first time we use that stream. For the rest of IO requests served by this stream ->private usually contains some temporarily data from the previous requests. Signed-off-by: Sergey Senozhatsky <[email protected]> Acked-by: Minchan Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> (cherry picked from commit e02d238c9852a91b30da9ea32ce36d1416cdc683) Signed-off-by: Peter Kalauskas <[email protected]> Bug: 112488418 Change-Id: I911832da703f596998a4139d6033ef1564848c9e
Signed-off-by: Michael Benedict <[email protected]>
Signed-off-by: Michael Benedict <[email protected]>
* Apex isn't able to write to it without S_IWUSR. Change-Id: I374b4acb3239bf1f3ab2109e4391671c85131be5
Signed-off-by: Michael Benedict <[email protected]>
system was early mounted and it doesnt have the time to import efs prop, so early mount efs too Signed-off-by: Michael Benedict <[email protected]>
Based on the public grsecurity patches.
…tional-locks
[ Upstream commit ff64dd4857303dd5550faed9fd598ac90f0f2238 ]
git-diff-index does not refresh the index for you, so using it for a
"-dirty" check can give misleading results. Commit 6147b1cf19651
("scripts/setlocalversion: git: Make -dirty check more robust") tried to
fix this by switching to git-status, but it overlooked the fact that
git-status also writes to the .git directory of the source tree, which
is definitely not kosher for an out-of-tree (O=) build. That is getting
reverted.
Fortunately, git-status now supports avoiding writing to the index via
the --no-optional-locks flag, as of git 2.14. It still calculates an
up-to-date index, but it avoids writing it out to the .git directory.
So, let's retry the solution from commit 6147b1cf19651 using this new
flag first, and if it fails, we assume this is an older version of git
and just use the old git-diff-index method.
It's hairy to get the 'grep -vq' (inverted matching) correct by stashing
the output of git-status (you have to be careful about the difference
betwen "empty stdin" and "blank line on stdin"), so just pipe the output
directly to grep and use a regex that's good enough for both the
git-status and git-diff-index version.
Change-Id: Ieb6e2ff2db99c081b17332136db860260d165385
Cc: Christian Kujau <[email protected]>
Cc: Guenter Roeck <[email protected]>
Suggested-by: Alexander Kapshuk <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
Tested-by: Genki Sky <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
While mtp_read is being executed and mtp_function_disable is called then all the eps will be disabled which will lead to NULL pointer dereference in usb_ep_align_maybe function which will subsequently try to access endpoint descriptors. Add spinlock protection in mtp_function_disable to avoid race between mtp_read and mtp_function_disable. Change-Id: If7f00ff2a98f75d2782e6bb35ad5fe59e4db6734 Signed-off-by: Pratham Pratap <[email protected]>
Change-Id: I2a37344987cbef9496b48ff1d1a8d9f0dc913f3e
Change-Id: I76ef0a3f15e1f58d58a6895bc764d5e9c180c166
Change-Id: I7d864c8141156ef8d6e5c08ad2829a13adaa00a7
Change-Id: Ib5b351ac865374331f93ef9aa9f58c2af8b6915e
Change-Id: Ife6638d4ce17a1e8f58c747b905b87257ebe170b
Change-Id: Ic8db56d29b69dfade03b28b1be9535c7da96527c
Change-Id: I00acbf1c674d63edb7d3ce3d693145c7580945ab
Change-Id: Ic062052928e84f6b065472a5dee4bf8a49fc964e
After LLVM revision r355672 [1], all known working kernel configurations fail to link [2]: ld: init/do_mounts.o: in function `prepare_namespace': do_mounts.c:(.init.text+0x5ca): undefined reference to `bcmp' ld: do_mounts.c:(.init.text+0x5e6): undefined reference to `bcmp' ld: init/initramfs.o: in function `do_header': initramfs.c:(.init.text+0x6e0): undefined reference to `bcmp' ld: initramfs.c:(.init.text+0x6f8): undefined reference to `bcmp' ld: arch/x86/kernel/setup.o: in function `setup_arch': setup.c:(.init.text+0x21d): undefined reference to `bcmp' Commit 6edfba1 ("[PATCH] x86_64: Don't define string functions to builtin") removed '-ffreestanding' globally and the kernel doesn't provide a bcmp definition so the linker cannot find a reference to it. Fix this by explicitly telling LLVM through Clang not to emit bcmp references. This flag does not need to be behind 'cc-option' because all working versions of Clang support this flag. [1]: llvm/llvm-project@8e16d73 [2]: https://travis-ci.com/ClangBuiltLinux/continuous-integration/builds/104027249 Link: ClangBuiltLinux/linux#416 Link: https://bugs.llvm.org/show_bug.cgi?id=41035 Cc: [email protected] Signed-off-by: Nathan Chancellor <[email protected]> Change-Id: Ide8b905b0406ef698916f07d728c7d5fd72978e2
drivers/net/wireless/bcmdhd4361/dhd_common.c:3839:19: error: comparing a pointer to a null character constant; did you mean to compare to N
ULL? [-Werror,-Wpointer-compare]
if (argv[i] == '\0') {
^~~~
(void *)0
Change-Id: I4b6613761ff3965cb8741046d4d62d2ea04a852e
drivers/scsi/ufs/ufshcd.c:7588:3: error: 'sprintf' will always overflow; destination buffer has size 16, but format string expands to at le
ast 17 [-Werror,-Wfortify-source]
sprintf(buf, "U%dH%dL%dX%dQ%dR%dW%dF%d",
^
Change-Id: Ic03043dc5df59faf7f19a03deb2fb2d558910db0
drivers/media/platform/exynos/fimc-is2/sensor/flite/fimc-is-hw-flite-v4_20_0.c:28:9: error: bitwise negation of a boolean expression; did you m
ean logical negation? [-Werror,-Wbool-operation]
cfg |= FLITE_REG_BINNINGON_CLKGATE_ON(enable);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/platform/exynos/fimc-is2/sensor/flite/fimc-is-hw-flite-v4_20_0.h:112:45: note: expanded from macro 'FLITE_REG_BINNINGON_CLKGATE_O
N'
Change-Id: I3974e42c46d235cae0ad4cfdd5d4cc0af7e7fafe
drivers/net/wireless/bcmdhd4361/wl_android.c:7107:22: error: overlapping comparisons always evaluate to false [-Werror,-Wtautological-overlap-compare]
if ((adps_mode < 0) && (1 < adps_mode)) {
Change-Id: Ic52de37d5048341a0851b011463522b4865d119a
drivers/media/platform/exynos/fimc-is2/vendor/mcd/fimc-is-sysfs.c:248:40: error: expression does not compute the number of elements in this arr
ay; element type is 'struct ssrm_camera_data', not 'int' [-Werror,-Wsizeof-array-div]
if (ret_count > sizeof(SsrmCameraInfo)/sizeof(int))
Change-Id: I2f3b33c7c1951cfa316a9cc59d87308564ffbd93
* much less overhead now - also, its barely making any diff in app launching speed after disabling iorap. tested using `adb logcat | grep Displayed` Change-Id: I824a55253e472fae7e1f6e0541f4a53eda18e4a9 Signed-off-by: SamarV-121 <[email protected]>
Change-Id: Ieeb06ec47ad0ffd795d85db0de811ba7eaec2998
Royna2544
pushed a commit
to Roynas-Android-Playground/android_kernel_samsung_universal8895
that referenced
this pull request
May 15, 2023
…g the sock [ Upstream commit 3cf7203ca620682165706f70a1b12b5194607dce ] There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 8890q#1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d 8890q#2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 8890q#3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b 8890q#4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb exynos8895#5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 exynos8895#6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 exynos8895#7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] exynos8895#8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 exynos8895#9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 exynos8895#10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 exynos8895#11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 exynos8895#12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde exynos8895#13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b exynos8895#14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 exynos8895#15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a exynos8895#16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 exynos8895#17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca exynos8895#18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock. Reported-by: Jianlin Shi <[email protected]> Suggested-by: Jakub Sitnicki <[email protected]> Fixes: 6a93cc9 ("udp-tunnel: Add a few more UDP tunnel APIs") Signed-off-by: Hangbin Liu <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Ulrich Hecht <[email protected]>
HarryPottreDev
pushed a commit
to HarryPottreDev/android_kernel_samsung_universal8895
that referenced
this pull request
Nov 8, 2024
ARM64 doesn't implement find_first_{zero}_bit in arch code and doesn't
enable it in a config. It leads to using find_next_bit() which is less
efficient:
0000000000000000 <find_first_bit>:
0: aa0003e4 mov x4, x0
4: aa0103e0 mov x0, x1
8: b4000181 cbz x1, 38 <find_first_bit+0x38>
c: f9400083 ldr x3, [x4]
10: d2800802 mov x2, #0x40 // #64
14: 91002084 add x4, x4, #0x8
18: b40000c3 cbz x3, 30 <find_first_bit+0x30>
1c: 14000008 b 3c <find_first_bit+0x3c>
20: f8408483 ldr x3, [x4], exynos8895#8
24: 91010045 add x5, x2, #0x40
28: b50000c3 cbnz x3, 40 <find_first_bit+0x40>
2c: aa0503e2 mov x2, x5
30: eb02001f cmp x0, x2
34: 54ffff68 b.hi 20 <find_first_bit+0x20> // b.pmore
38: d65f03c0 ret
3c: d2800002 mov x2, #0x0 // #0
40: dac00063 rbit x3, x3
44: dac01063 clz x3, x3
48: 8b020062 add x2, x3, x2
4c: eb02001f cmp x0, x2
50: 9a829000 csel x0, x0, x2, ls // ls = plast
54: d65f03c0 ret
...
0000000000000118 <_find_next_bit.constprop.1>:
118: eb02007f cmp x3, x2
11c: 540002e2 b.cs 178 <_find_next_bit.constprop.1+0x60> // b.hs, b.nlast
120: d346fc66 lsr x6, x3, exynos8895#6
124: f8667805 ldr x5, [x0, x6, lsl 8890q#3]
128: b4000061 cbz x1, 134 <_find_next_bit.constprop.1+0x1c>
12c: f8667826 ldr x6, [x1, x6, lsl 8890q#3]
130: 8a0600a5 and x5, x5, x6
134: ca0400a6 eor x6, x5, x4
138: 92800005 mov x5, #0xffffffffffffffff // #-1
13c: 9ac320a5 lsl x5, x5, x3
140: 927ae463 and x3, x3, #0xffffffffffffffc0
144: ea0600a5 ands x5, x5, x6
148: 54000120 b.eq 16c <_find_next_bit.constprop.1+0x54> // b.none
14c: 1400000e b 184 <_find_next_bit.constprop.1+0x6c>
150: d346fc66 lsr x6, x3, exynos8895#6
154: f8667805 ldr x5, [x0, x6, lsl 8890q#3]
158: b4000061 cbz x1, 164 <_find_next_bit.constprop.1+0x4c>
15c: f8667826 ldr x6, [x1, x6, lsl 8890q#3]
160: 8a0600a5 and x5, x5, x6
164: eb05009f cmp x4, x5
168: 540000c1 b.ne 180 <_find_next_bit.constprop.1+0x68> // b.any
16c: 91010063 add x3, x3, #0x40
170: eb03005f cmp x2, x3
174: 54fffee8 b.hi 150 <_find_next_bit.constprop.1+0x38> // b.pmore
178: aa0203e0 mov x0, x2
17c: d65f03c0 ret
180: ca050085 eor x5, x4, x5
184: dac000a5 rbit x5, x5
188: dac010a5 clz x5, x5
18c: 8b0300a3 add x3, x5, x3
190: eb03005f cmp x2, x3
194: 9a839042 csel x2, x2, x3, ls // ls = plast
198: aa0203e0 mov x0, x2
19c: d65f03c0 ret
...
0000000000000238 <find_next_bit>:
238: a9bf7bfd stp x29, x30, [sp, #-16]!
23c: aa0203e3 mov x3, x2
240: d2800004 mov x4, #0x0 // #0
244: aa0103e2 mov x2, x1
248: 910003fd mov x29, sp
24c: d2800001 mov x1, #0x0 // #0
250: 97ffffb2 bl 118 <_find_next_bit.constprop.1>
254: a8c17bfd ldp x29, x30, [sp], exynos8895#16
258: d65f03c0 ret
Enabling find_{first,next}_bit() would also benefit for_each_{set,clear}_bit().
On A-53 find_first_bit() is almost twice faster than find_next_bit(), according
to lib/find_bit_benchmark (thanks to Alexey for testing):
GENERIC_FIND_FIRST_BIT=n:
[7126084.948181] find_first_bit: 47389224 ns, 16357 iterations
[7126085.032315] find_first_bit: 19048193 ns, 655 iterations
GENERIC_FIND_FIRST_BIT=y:
[ 84.158068] find_first_bit: 27193319 ns, 16406 iterations
[ 84.233005] find_first_bit: 11082437 ns, 656 iterations
GENERIC_FIND_FIRST_BIT=n bloats the kernel despite that it disables generation
of find_{first,next}_bit():
yury:linux$ scripts/bloat-o-meter vmlinux vmlinux.ffb
add/remove: 4/1 grow/shrink: 19/251 up/down: 564/-1692 (-1128)
...
Overall, GENERIC_FIND_FIRST_BIT=n is harmful both in terms of performance and
code size, and it's better to have GENERIC_FIND_FIRST_BIT enabled.
Tested-by: Alexey Klimov <[email protected]>
Signed-off-by: Yury Norov <[email protected]>
Acked-by: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Forenche <[email protected]>
HarryPottreDev
pushed a commit
to HarryPottreDev/android_kernel_samsung_universal8895
that referenced
this pull request
Nov 9, 2024
ARM64 doesn't implement find_first_{zero}_bit in arch code and doesn't
enable it in a config. It leads to using find_next_bit() which is less
efficient:
0000000000000000 <find_first_bit>:
0: aa0003e4 mov x4, x0
4: aa0103e0 mov x0, x1
8: b4000181 cbz x1, 38 <find_first_bit+0x38>
c: f9400083 ldr x3, [x4]
10: d2800802 mov x2, #0x40 // #64
14: 91002084 add x4, x4, #0x8
18: b40000c3 cbz x3, 30 <find_first_bit+0x30>
1c: 14000008 b 3c <find_first_bit+0x3c>
20: f8408483 ldr x3, [x4], exynos8895#8
24: 91010045 add x5, x2, #0x40
28: b50000c3 cbnz x3, 40 <find_first_bit+0x40>
2c: aa0503e2 mov x2, x5
30: eb02001f cmp x0, x2
34: 54ffff68 b.hi 20 <find_first_bit+0x20> // b.pmore
38: d65f03c0 ret
3c: d2800002 mov x2, #0x0 // #0
40: dac00063 rbit x3, x3
44: dac01063 clz x3, x3
48: 8b020062 add x2, x3, x2
4c: eb02001f cmp x0, x2
50: 9a829000 csel x0, x0, x2, ls // ls = plast
54: d65f03c0 ret
...
0000000000000118 <_find_next_bit.constprop.1>:
118: eb02007f cmp x3, x2
11c: 540002e2 b.cs 178 <_find_next_bit.constprop.1+0x60> // b.hs, b.nlast
120: d346fc66 lsr x6, x3, exynos8895#6
124: f8667805 ldr x5, [x0, x6, lsl 8890q#3]
128: b4000061 cbz x1, 134 <_find_next_bit.constprop.1+0x1c>
12c: f8667826 ldr x6, [x1, x6, lsl 8890q#3]
130: 8a0600a5 and x5, x5, x6
134: ca0400a6 eor x6, x5, x4
138: 92800005 mov x5, #0xffffffffffffffff // #-1
13c: 9ac320a5 lsl x5, x5, x3
140: 927ae463 and x3, x3, #0xffffffffffffffc0
144: ea0600a5 ands x5, x5, x6
148: 54000120 b.eq 16c <_find_next_bit.constprop.1+0x54> // b.none
14c: 1400000e b 184 <_find_next_bit.constprop.1+0x6c>
150: d346fc66 lsr x6, x3, exynos8895#6
154: f8667805 ldr x5, [x0, x6, lsl 8890q#3]
158: b4000061 cbz x1, 164 <_find_next_bit.constprop.1+0x4c>
15c: f8667826 ldr x6, [x1, x6, lsl 8890q#3]
160: 8a0600a5 and x5, x5, x6
164: eb05009f cmp x4, x5
168: 540000c1 b.ne 180 <_find_next_bit.constprop.1+0x68> // b.any
16c: 91010063 add x3, x3, #0x40
170: eb03005f cmp x2, x3
174: 54fffee8 b.hi 150 <_find_next_bit.constprop.1+0x38> // b.pmore
178: aa0203e0 mov x0, x2
17c: d65f03c0 ret
180: ca050085 eor x5, x4, x5
184: dac000a5 rbit x5, x5
188: dac010a5 clz x5, x5
18c: 8b0300a3 add x3, x5, x3
190: eb03005f cmp x2, x3
194: 9a839042 csel x2, x2, x3, ls // ls = plast
198: aa0203e0 mov x0, x2
19c: d65f03c0 ret
...
0000000000000238 <find_next_bit>:
238: a9bf7bfd stp x29, x30, [sp, #-16]!
23c: aa0203e3 mov x3, x2
240: d2800004 mov x4, #0x0 // #0
244: aa0103e2 mov x2, x1
248: 910003fd mov x29, sp
24c: d2800001 mov x1, #0x0 // #0
250: 97ffffb2 bl 118 <_find_next_bit.constprop.1>
254: a8c17bfd ldp x29, x30, [sp], exynos8895#16
258: d65f03c0 ret
Enabling find_{first,next}_bit() would also benefit for_each_{set,clear}_bit().
On A-53 find_first_bit() is almost twice faster than find_next_bit(), according
to lib/find_bit_benchmark (thanks to Alexey for testing):
GENERIC_FIND_FIRST_BIT=n:
[7126084.948181] find_first_bit: 47389224 ns, 16357 iterations
[7126085.032315] find_first_bit: 19048193 ns, 655 iterations
GENERIC_FIND_FIRST_BIT=y:
[ 84.158068] find_first_bit: 27193319 ns, 16406 iterations
[ 84.233005] find_first_bit: 11082437 ns, 656 iterations
GENERIC_FIND_FIRST_BIT=n bloats the kernel despite that it disables generation
of find_{first,next}_bit():
yury:linux$ scripts/bloat-o-meter vmlinux vmlinux.ffb
add/remove: 4/1 grow/shrink: 19/251 up/down: 564/-1692 (-1128)
...
Overall, GENERIC_FIND_FIRST_BIT=n is harmful both in terms of performance and
code size, and it's better to have GENERIC_FIND_FIRST_BIT enabled.
Tested-by: Alexey Klimov <[email protected]>
Signed-off-by: Yury Norov <[email protected]>
Acked-by: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Forenche <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thanks