Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

device tree support for adm1278 #64

Open
shenki opened this issue Mar 21, 2016 · 11 comments
Open

device tree support for adm1278 #64

shenki opened this issue Mar 21, 2016 · 11 comments
Assignees

Comments

@shenki
Copy link
Member

shenki commented Mar 21, 2016

Following from the discussion in openbmc/openbmc#212 (comment), we need extra features not present in the upstream driver:

@adamliyi can you please review these changes for me, and if you are happy with them, I will add them to our kernel tree

@shenki shenki self-assigned this Mar 21, 2016
@shenki
Copy link
Member Author

shenki commented Mar 21, 2016

[   13.450000] adm1275 4-0010: using r_sense from dt 500
[   13.520000] adm1275 5-0010: using r_sense from dt 500
[   13.580000] adm1275 6-0010: using r_sense from dt 500
# sensors 
adm1278-i2c-4-10
Adapter: Aspeed i2c-4
vin:         +12.07 V  (min =  +0.00 V, max = +20.89 V)
                       (highest = +12.11 V)
pin:           0.00 W  (highest = -184.00 uW, max = -117.00 uW)
iout1:        +0.00 A  (max =  +0.05 A, highest =  +0.00 A)

adm1278-i2c-5-10
Adapter: Aspeed i2c-5
vin:         +12.07 V  (min =  +0.00 V, max = +20.89 V)
                       (highest = +12.13 V)
pin:           4.00 uW (highest = 341.00 uW, max = -117.00 uW)
iout1:        +0.00 A  (max =  +0.05 A, highest =  +0.00 A)

adm1278-i2c-6-10
Adapter: Aspeed i2c-6
vin:         +12.07 V  (min =  +0.00 V, max = +20.89 V)
                       (highest = +12.07 V)
pin:         -520.00 uW (highest = -697.00 uW, max = -117.00 uW)
iout1:        +0.00 A  (max =  +0.05 A, highest =  +0.00 A)

@adamliyi
Copy link
Member

@shenki . I agree this is a better solution. The code looks OK with me. I will do more test on HW (to check the sensors we want are there) today.

@shenki
Copy link
Member Author

shenki commented Mar 22, 2016

@adamliyi I added the three to the device tree that you mentioned in your patches. The output is pasted in the comment above. Are the numbers correct?

@mdmillerii
Copy link

The user space framework already supports a scale factor, so that patch could be delayed. Instancing from the device tree is required.

I think a generic scaling framework for all hwmon sensors should be proposed instead of a one off feature for one driver.

@adamliyi
Copy link
Member

Hi Joel,

With @mdmillerii 's comments, and I read again the document you mentioned:

(https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface):

    Actual voltage depends on the scaling resistors on the motherboard, as
    recommended in the chip datasheet. This varies by chip and by motherboard.
    Because of this variation, values are generally NOT scaled by the chip driver,
    and must be done by the application. However, some drivers (notably lm87 and
    via686a) do scale, because of internal resistors built into a chip. These
    drivers will output the actual voltage. Rule of thumb: drivers should report
    the voltage values at the "pins" of the chip.

So it looks we using a "scale factor" for the sense resistor in user space make more sense? In obmc's case, we can set the "scale factor" in skeleton.

BTW, the sensor resistor value on Barreleye is 250 microohms.

@shenki
Copy link
Member Author

shenki commented Mar 29, 2016

I have sent the device tree change upstream: http://article.gmane.org/gmane.linux.kernel.hwmon/24

I disagree with upstream; in the case of the device tree we have a well suited mechanism to do scaling in the kernel. However, until we convince them of this, I will back out the change to do the scaling in the device tree and we will scale from userspace.

@adamliyi can you please send a patch to perform the scaling in userspace?

@shenki
Copy link
Member Author

shenki commented Mar 29, 2016

The change is backed out as of c2f2e9f and https:/openbmc/linux/releases/tag/openbmc-20160329-2

@adamliyi
Copy link
Member

@shenki ,
Hi Joel, I just found there might be some issue with the upstream adm1278 hwmon driver. Some sensors are missing, e.g, "in2_input". This stands for "Vout" register in adm1278. Customer will need this sensor.

Here is the sensors currently available:

root@barreleye:~# cat /sys/class/hwmon/hwmon3/
curr1_highest         in1_label             power1_alarm
curr1_input           in1_max               power1_input
curr1_label           in1_max_alarm         power1_input_highest
curr1_max             in1_min               power1_label
curr1_max_alarm       in1_min_alarm         power1_max
curr1_reset_history   in1_reset_history     power1_reset_history
device/               name                  subsystem/
in1_highest           of_node/              uevent
in1_input             power/                
root@barreleye:~# cat /sys/class/hwmon/hwmon3/in1_input 
11990
root@barreleye:~# cat /sys/class/hwmon/hwmon3/in1_label  
vin

We will need

/sys/class/hwmon/hwmon3/in2_input

Kernel version:

root@barreleye:~# uname -a
Linux barreleye 4.4.6-openbmc-20160329-2 #1 Wed Apr 20 23:06:07 CST 2016 armv5tejl GNU/Linux
root@barreleye:~# cat /proc/version  
Linux version 4.4.6-openbmc-20160329-2 (adam@ubuntu) (gcc version 4.9.3 (GCC) ) #1 Wed Apr 20 23:06:07 CST 2016

I might need to add another issue to track this problem.

@shenki
Copy link
Member Author

shenki commented Apr 22, 2016

@adamliyi Could you add support to the existing upstream driver for these extra readings?

@adamliyi
Copy link
Member

OK. I will dig into it.

@adamliyi
Copy link
Member

Sensor resistor value added as a scale value in skeleton. Please see: openbmc/skeleton#57.

eddiejames pushed a commit to eddiejames/linux that referenced this issue Jul 10, 2018
Check for Resolv list supported by controller. So check the supported
commmand first before issuing this command i.e.,HCI_OP_LE_CLEAR_RESOLV_LIST

Before patch:
< HCI Command: LE Read White List... (0x08|0x000f) plen 0  openbmc#55 [hci0] 13.338168
> HCI Event: Command Complete (0x0e) plen 5                openbmc#56 [hci0] 13.338842
      LE Read White List Size (0x08|0x000f) ncmd 1
        Status: Success (0x00)
        Size: 25
< HCI Command: LE Clear White List (0x08|0x0010) plen 0    openbmc#57 [hci0] 13.339029
> HCI Event: Command Complete (0x0e) plen 4                openbmc#58 [hci0] 13.339939
      LE Clear White List (0x08|0x0010) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Read Resolving L.. (0x08|0x002a) plen 0  openbmc#59 [hci0] 13.340152
> HCI Event: Command Complete (0x0e) plen 5                openbmc#60 [hci0] 13.340952
      LE Read Resolving List Size (0x08|0x002a) ncmd 1
        Status: Success (0x00)
        Size: 25
< HCI Command: LE Read Maximum Dat.. (0x08|0x002f) plen 0  openbmc#61 [hci0] 13.341180
> HCI Event: Command Complete (0x0e) plen 12               openbmc#62 [hci0] 13.341898
      LE Read Maximum Data Length (0x08|0x002f) ncmd 1
        Status: Success (0x00)
        Max TX octets: 251
        Max TX time: 17040
        Max RX octets: 251
        Max RX time: 17040

After patch:
< HCI Command: LE Read White List... (0x08|0x000f) plen 0  openbmc#55 [hci0] 28.919131
> HCI Event: Command Complete (0x0e) plen 5                openbmc#56 [hci0] 28.920016
      LE Read White List Size (0x08|0x000f) ncmd 1
        Status: Success (0x00)
        Size: 25
< HCI Command: LE Clear White List (0x08|0x0010) plen 0    openbmc#57 [hci0] 28.920164
> HCI Event: Command Complete (0x0e) plen 4                openbmc#58 [hci0] 28.920873
      LE Clear White List (0x08|0x0010) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Read Resolving L.. (0x08|0x002a) plen 0  openbmc#59 [hci0] 28.921109
> HCI Event: Command Complete (0x0e) plen 5                openbmc#60 [hci0] 28.922016
      LE Read Resolving List Size (0x08|0x002a) ncmd 1
        Status: Success (0x00)
        Size: 25
< HCI Command: LE Clear Resolving... (0x08|0x0029) plen 0  openbmc#61 [hci0] 28.922166
> HCI Event: Command Complete (0x0e) plen 4                openbmc#62 [hci0] 28.922872
      LE Clear Resolving List (0x08|0x0029) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Read Maximum Dat.. (0x08|0x002f) plen 0  openbmc#63 [hci0] 28.923117
> HCI Event: Command Complete (0x0e) plen 12               openbmc#64 [hci0] 28.924030
      LE Read Maximum Data Length (0x08|0x002f) ncmd 1
        Status: Success (0x00)
        Max TX octets: 251
        Max TX time: 17040
        Max RX octets: 251
        Max RX time: 17040

Signed-off-by: Ankit Navik <[email protected]>
Signed-off-by: Marcel Holtmann <[email protected]>
shenki pushed a commit that referenced this issue Aug 22, 2019
commit b803974 upstream.

This fixes the below calltrace when the CONFIG_DMA_API_DEBUG is enabled.
  DMA-API: thunderx_mmc 0000:01:01.4: cpu touching an active dma mapped cacheline [cln=0x000000002fdf9800]
  WARNING: CPU: 21 PID: 1 at kernel/dma/debug.c:596 debug_dma_assert_idle+0x1f8/0x270
  Modules linked in:
  CPU: 21 PID: 1 Comm: init Not tainted 5.3.0-rc1-next-20190725-yocto-standard+ #64
  Hardware name: Marvell OcteonTX CN96XX board (DT)
  pstate: 80400009 (Nzcv daif +PAN -UAO)
  pc : debug_dma_assert_idle+0x1f8/0x270
  lr : debug_dma_assert_idle+0x1f8/0x270
  sp : ffff0000113cfc10
  x29: ffff0000113cfc10 x28: 0000ffff8c880000
  x27: ffff800bc72a0000 x26: ffff000010ff8000
  x25: ffff000010ff8940 x24: ffff000010ff8968
  x23: 0000000000000000 x22: ffff000010e83700
  x21: ffff000010ea2000 x20: ffff000010e835c8
  x19: ffff800bc2c73300 x18: ffffffffffffffff
  x17: 0000000000000000 x16: 0000000000000000
  x15: ffff000010e835c8 x14: 6d20616d64206576
  x13: 69746361206e6120 x12: 676e696863756f74
  x11: 20757063203a342e x10: 31303a31303a3030
  x9 : 303020636d6d5f78 x8 : 3230303030303030
  x7 : 00000000000002fd x6 : ffff000010fd57d0
  x5 : 0000000000000000 x4 : ffff0000106c5210
  x3 : 00000000ffffffff x2 : 0000800bee9c0000
  x1 : 57d5843f4aa62800 x0 : 0000000000000000
  Call trace:
   debug_dma_assert_idle+0x1f8/0x270
   wp_page_copy+0xb0/0x688
   do_wp_page+0xa8/0x5b8
   __handle_mm_fault+0x600/0xd00
   handle_mm_fault+0x118/0x1e8
   do_page_fault+0x200/0x500
   do_mem_abort+0x50/0xb0
   el0_da+0x20/0x24
  ---[ end trace a005534bd23e109f ]---
  DMA-API: Mapped at:
   debug_dma_map_sg+0x94/0x350
   cvm_mmc_request+0x3c4/0x988
   __mmc_start_request+0x9c/0x1f8
   mmc_start_request+0x7c/0xb0
   mmc_blk_mq_issue_rq+0x5c4/0x7b8

Signed-off-by: Kevin Hao <[email protected]>
Fixes: ba3869f ("mmc: cavium: Add core MMC driver for Cavium SOCs")
Cc: [email protected]
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
shenki pushed a commit that referenced this issue Oct 7, 2019
[ Upstream commit c7b6804 ]

Building a combined ARMv4+XScale kernel produces these
and other build failures:

/tmp/copypage-xscale-3aa821.s: Assembler messages:
/tmp/copypage-xscale-3aa821.s:167: Error: selected processor does not support `pld [r7,#0]' in ARM mode
/tmp/copypage-xscale-3aa821.s:168: Error: selected processor does not support `pld [r7,#32]' in ARM mode
/tmp/copypage-xscale-3aa821.s:169: Error: selected processor does not support `pld [r1,#0]' in ARM mode
/tmp/copypage-xscale-3aa821.s:170: Error: selected processor does not support `pld [r1,#32]' in ARM mode
/tmp/copypage-xscale-3aa821.s:171: Error: selected processor does not support `pld [r7,#64]' in ARM mode
/tmp/copypage-xscale-3aa821.s:176: Error: selected processor does not support `ldrd r4,r5,[r7],#8' in ARM mode
/tmp/copypage-xscale-3aa821.s:180: Error: selected processor does not support `strd r4,r5,[r1],#8' in ARM mode

Add an explict .arch armv5 in the inline assembly to allow the ARMv5
specific instructions regardless of the compiler -march= target.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
shenki added a commit that referenced this issue Jun 4, 2021
When setting up a read or write to the OPB memory space, we must perform
five or six AHB writes. The ordering of these up until the trigger write
does not matter, so use writel_relaxed.

The generated code goes from (Debian GCC 10.2.1-6):

        mov     r8, r3
        mcr     15, 0, sl, cr7, cr10, {4}
        str     sl, [r6, #20]
        mcr     15, 0, sl, cr7, cr10, {4}
        str     r3, [r6, #24]
        mcr     15, 0, sl, cr7, cr10, {4}
        str     r1, [r6, #28]
        mcr     15, 0, sl, cr7, cr10, {4}
        str     r2, [r6, #32]
        mcr     15, 0, sl, cr7, cr10, {4}
        mov     r1, #1
        str     r1, [r6, #64]   ; 0x40
        mcr     15, 0, sl, cr7, cr10, {4}
        str     r1, [r6, #4]

to this:

        str     r3, [r7, #20]
        str     r2, [r7, #24]
        str     r1, [r7, #28]
        str     r3, [r7, #64]
        mov     r8, #0
        mcr     15, 0, r8, cr7, cr10, {4}
        str     r3, [r7, #4]

OpenBMC-Staging-Count: 1
Signed-off-by: Joel Stanley <[email protected]>
Acked-by: Jeremy Kerr <[email protected]>
Reviewed-by: Eddie James <[email protected]>
Tested-by: Eddie James <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joel Stanley <[email protected]>
shenki pushed a commit that referenced this issue Feb 17, 2022
commit 8b59b0a upstream.

arm32 uses software to simulate the instruction replaced
by kprobe. some instructions may be simulated by constructing
assembly functions. therefore, before executing instruction
simulation, it is necessary to construct assembly function
execution environment in C language through binding registers.
after kasan is enabled, the register binding relationship will
be destroyed, resulting in instruction simulation errors and
causing kernel panic.

the kprobe emulate instruction function is distributed in three
files: actions-common.c actions-arm.c actions-thumb.c, so disable
KASAN when compiling these files.

for example, use kprobe insert on cap_capable+20 after kasan
enabled, the cap_capable assembly code is as follows:
<cap_capable>:
e92d47f0	push	{r4, r5, r6, r7, r8, r9, sl, lr}
e1a05000	mov	r5, r0
e280006c	add	r0, r0, #108    ; 0x6c
e1a04001	mov	r4, r1
e1a06002	mov	r6, r2
e59fa090	ldr	sl, [pc, #144]  ;
ebfc7bf8	bl	c03aa4b4 <__asan_load4>
e595706c	ldr	r7, [r5, #108]  ; 0x6c
e2859014	add	r9, r5, #20
......
The emulate_ldr assembly code after enabling kasan is as follows:
c06f1384 <emulate_ldr>:
e92d47f0	push	{r4, r5, r6, r7, r8, r9, sl, lr}
e282803c	add	r8, r2, #60     ; 0x3c
e1a05000	mov	r5, r0
e7e37855	ubfx	r7, r5, #16, #4
e1a00008	mov	r0, r8
e1a09001	mov	r9, r1
e1a04002	mov	r4, r2
ebf35462	bl	c03c6530 <__asan_load4>
e357000f	cmp	r7, #15
e7e36655	ubfx	r6, r5, #12, #4
e205a00f	and	sl, r5, #15
0a000001	beq	c06f13bc <emulate_ldr+0x38>
e0840107	add	r0, r4, r7, lsl #2
ebf3545c	bl	c03c6530 <__asan_load4>
e084010a	add	r0, r4, sl, lsl #2
ebf3545a	bl	c03c6530 <__asan_load4>
e2890010	add	r0, r9, #16
ebf35458	bl	c03c6530 <__asan_load4>
e5990010	ldr	r0, [r9, #16]
e12fff30	blx	r0
e356000f	cm	r6, #15
1a000014	bne	c06f1430 <emulate_ldr+0xac>
e1a06000	mov	r6, r0
e2840040	add	r0, r4, #64     ; 0x40
......

when running in emulate_ldr to simulate the ldr instruction, panic
occurred, and the log is as follows:
Unable to handle kernel NULL pointer dereference at virtual address
00000090
pgd = ecb46400
[00000090] *pgd=2e0fa003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP ARM
PC is at cap_capable+0x14/0xb0
LR is at emulate_ldr+0x50/0xc0
psr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c
r10: 00000000  r9 : c30897f4  r8 : ecd63cd4
r7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98
r3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 32c5387d  Table: 2d546400  DAC: 55555555
Process bash (pid: 1643, stack limit = 0xecd60190)
(cap_capable) from (kprobe_handler+0x218/0x340)
(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
(do_undefinstr) from (__und_svc_finish+0x0/0x30)
(__und_svc_finish) from (cap_capable+0x18/0xb0)
(cap_capable) from (cap_vm_enough_memory+0x38/0x48)
(cap_vm_enough_memory) from
(security_vm_enough_memory_mm+0x48/0x6c)
(security_vm_enough_memory_mm) from
(copy_process.constprop.5+0x16b4/0x25c8)
(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
(_do_fork) from (SyS_clone+0x1c/0x24)
(SyS_clone) from (__sys_trace_return+0x0/0x10)
Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)

Fixes: 35aa1df ("ARM kprobes: instruction single-stepping support")
Fixes: 4210157 ("ARM: 9017/2: Enable KASan for ARM")
Signed-off-by: huangshaobo <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
shenki pushed a commit that referenced this issue Oct 26, 2023
commit 6d41d4f upstream.

BUG: KASAN: slab-use-after-free in xfrm_policy_inexact_list_reinsert+0xb6/0x430
Read of size 1 at addr ffff8881051f3bf8 by task ip/668

CPU: 2 PID: 668 Comm: ip Not tainted 6.5.0-rc5-00182-g25aa0bebba72-dirty #64
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x72/0xa0
 print_report+0xd0/0x620
 kasan_report+0xb6/0xf0
 xfrm_policy_inexact_list_reinsert+0xb6/0x430
 xfrm_policy_inexact_insert_node.constprop.0+0x537/0x800
 xfrm_policy_inexact_alloc_chain+0x23f/0x320
 xfrm_policy_inexact_insert+0x6b/0x590
 xfrm_policy_insert+0x3b1/0x480
 xfrm_add_policy+0x23c/0x3c0
 xfrm_user_rcv_msg+0x2d0/0x510
 netlink_rcv_skb+0x10d/0x2d0
 xfrm_netlink_rcv+0x49/0x60
 netlink_unicast+0x3fe/0x540
 netlink_sendmsg+0x528/0x970
 sock_sendmsg+0x14a/0x160
 ____sys_sendmsg+0x4fc/0x580
 ___sys_sendmsg+0xef/0x160
 __sys_sendmsg+0xf7/0x1b0
 do_syscall_64+0x3f/0x90
 entry_SYSCALL_64_after_hwframe+0x73/0xdd

The root cause is:

cpu 0			cpu1
xfrm_dump_policy
xfrm_policy_walk
list_move_tail
			xfrm_add_policy
			... ...
			xfrm_policy_inexact_list_reinsert
			list_for_each_entry_reverse
				if (!policy->bydst_reinsert)
				//read non-existent policy
xfrm_dump_policy_done
xfrm_policy_walk_done
list_del(&walk->walk.all);

If dump_one_policy() returns err (triggered by netlink socket),
xfrm_policy_walk() will move walk initialized by socket to list
net->xfrm.policy_all. so this socket becomes visible in the global
policy list. The head *walk can be traversed when users add policies
with different prefixlen and trigger xfrm_policy node merge.

The issue can also be triggered by policy list traversal while rehashing
and flushing policies.

It can be fixed by skip such "policies" with walk.dead set to 1.

Fixes: 9cf545e ("xfrm: policy: store inexact policies in a tree ordered by destination address")
Fixes: 12a169e ("ipsec: Put dumpers on the dump list")
Signed-off-by: Dong Chenchen <[email protected]>
Signed-off-by: Steffen Klassert <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
amboar pushed a commit that referenced this issue Aug 30, 2024
commit 9a2fa14 upstream.

copy_fd_bitmaps(new, old, count) is expected to copy the first
count/BITS_PER_LONG bits from old->full_fds_bits[] and fill
the rest with zeroes.  What it does is copying enough words
(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.
That works fine, *if* all bits past the cutoff point are
clear.  Otherwise we are risking garbage from the last word
we'd copied.

For most of the callers that is true - expand_fdtable() has
count equal to old->max_fds, so there's no open descriptors
past count, let alone fully occupied words in ->open_fds[],
which is what bits in ->full_fds_bits[] correspond to.

The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),
which is the smallest multiple of BITS_PER_LONG that covers all
opened descriptors below max_fds.  In the common case (copying on
fork()) max_fds is ~0U, so all opened descriptors will be below
it and we are fine, by the same reasons why the call in expand_fdtable()
is safe.

Unfortunately, there is a case where max_fds is less than that
and where we might, indeed, end up with junk in ->full_fds_bits[] -
close_range(from, to, CLOSE_RANGE_UNSHARE) with
	* descriptor table being currently shared
	* 'to' being above the current capacity of descriptor table
	* 'from' being just under some chunk of opened descriptors.
In that case we end up with observably wrong behaviour - e.g. spawn
a child with CLONE_FILES, get all descriptors in range 0..127 open,
then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending
up with descriptor #128, despite #64 being observably not open.

The minimally invasive fix would be to deal with that in dup_fd().
If this proves to add measurable overhead, we can go that way, but
let's try to fix copy_fd_bitmaps() first.

* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
* make copy_fd_bitmaps() take the bitmap size in words, rather than
bits; it's 'count' argument is always a multiple of BITS_PER_LONG,
so we are not losing any information, and that way we can use the
same helper for all three bitmaps - compiler will see that count
is a multiple of BITS_PER_LONG for the large ones, so it'll generate
plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/close_range_test.c

Cc: [email protected]
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants