freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #64721] segfault when exceeding 1024 fd - replace select() by poll(


From: anonymous
Subject: [bug #64721] segfault when exceeding 1024 fd - replace select() by poll() in ipmi-openipmi-driver.c
Date: Wed, 27 Sep 2023 09:14:28 -0400 (EDT)

URL:
  <https://savannah.gnu.org/bugs/?64721>

                 Summary: segfault when exceeding 1024 fd - replace select()
by poll() in ipmi-openipmi-driver.c
                   Group: GNU FreeIPMI
               Submitter: None
               Submitted: Wed 27 Sep 2023 01:14:26 PM UTC
                Category: libfreeipmi
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Wed 27 Sep 2023 01:14:26 PM UTC By: Anonymous
In libfreeipmi/driver/ipmi-openipmi-driver.c we loop on select() call.

According to select man(2):

       WARNING:  select() can monitor only file descriptors numbers that are
less than FD_SETSIZE
       (1024)—an unreasonably low limit for many modern applications—and
this limitation will not
       change.  All modern applications should instead use poll(2) or
epoll(7), which do not suf‐
       fer this limitation.

This causes a segfault if the application has >=1024 fd open when trying to
open the openipmi driver. This happens easily in multithreaded applications
like Slurm (slurmd) when managing many RPCs. See bug
https://bugs.schedmd.com/show_bug.cgi?id=17639

See an excerpt of the core file from the Slurm bug 17639:

Thread 1 (Thread 0x14c5ed8b5700 (LWP 53050)):
#0  0x000014c5ef6b2c6b in raise () from /lib64/libc.so.6
#1  0x000014c5ef6b4305 in abort () from /lib64/libc.so.6
#2  0x000014c5ef6f8a97 in __libc_message () from /lib64/libc.so.6
#3  0x000014c5ef790812 in __fortify_fail () from /lib64/libc.so.6
#4  0x000014c5ef78ec40 in __chk_fail () from /lib64/libc.so.6
#5  0x000014c5ef79071a in __fdelt_warn () from /lib64/libc.so.6
#6  0x000014c5ee42a8c4 in ?? () from /usr/lib64/libfreeipmi.so.17
#7  0x000014c5ee42aecf in ipmi_openipmi_cmd () from
/usr/lib64/libfreeipmi.so.17
#8  0x000014c5ee40a0ab in ?? () from /usr/lib64/libfreeipmi.so.17
#9  0x000014c5ee3f75e7 in ipmi_cmd () from /usr/lib64/libfreeipmi.so.17
#10 0x000014c5ee3f8568 in ?? () from /usr/lib64/libfreeipmi.so.17
#11 0x000014c5ee3fab15 in ipmi_cmd_dcmi_get_power_reading () from
/usr/lib64/libfreeipmi.so.17
#12 0x000014c5eebded89 in _get_dcmi_power_reading (dcmi_mode=<optimized out>)
at acct_gather_energy_ipmi.c:500
#13 _read_ipmi_dcmi_values () at acct_gather_energy_ipmi.c:526
#14 _read_ipmi_values () at acct_gather_energy_ipmi.c:642
#15 _thread_update_node_energy () at acct_gather_energy_ipmi.c:696
#16 0x000014c5eebe096b in acct_gather_energy_p_get_data (data_type=<optimized
out>, data=0x14c5dc0f4a10) at acct_gather_energy_ipmi.c:1187
#17 0x000014c5f03ee3ab in acct_gather_energy_g_get_data (context_id=0,
data_type=data_type@entry=ENERGY_DATA_JOULES_TASK, data=0x14c5dc0f4a10) at
acct_gather_energy.c:362
#18 0x000000000041691e in _rpc_acct_gather_energy
(msg=msg@entry=0x14c5dc001350) at req.c:3431
#19 0x000000000041e353 in slurmd_req (msg=msg@entry=0x14c5dc001350) at
req.c:388
#20 0x000000000040dc37 in _service_connection (arg=<optimized out>) at
slurmd.c:625
#21 0x000014c5ef9db6ea in start_thread () from /lib64/libpthread.so.0
#22 0x000014c5ef77f94f in clone () from /lib64/libc.so.6

It seems natural that the select() call must be replaced by poll() to support
applications with more than 1024 opened fds.








    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64721>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]