ltp-ddt sometimes cannot find scripts/basic/fixdep #1
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
Added the make_scripts task to the ltp-ddt bitbake recipe. If no task has created the kernel scripts before ltp-ddt is run, there is a compile error complaining that it cannot find scripts/basic/fixdep. This patch ensures that these scripts are built before compiling starts.
philb
pushed a commit
that referenced
this pull request
Jul 8, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Jul 15, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Jul 15, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Jul 16, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Jul 27, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Jul 29, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Jul 30, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Jul 31, 2015
The bluetooth.service runs bluetoothd to manage bluetooth devices, if present, in the system. By design, it should be running in either of two cases: 1. A userspace utility (e.g. networkmanager) has made a dbus request for bluetooth services provided by org.bluez. Even without this patch, the bluetooth.service gets run via dbus activation under the systmed aliased name 'dbus-org-bluez.service'. Perfect! 2. A bluetooth device is added to the system. When a bluetooth device is added, udev triggers the special systemd target, bluetooth.target intended to pull in any services needed for bluetooth linked under bluetooth.target.wants. Enable bluetooth.service so it gets linked under bluetooth.target.wants and bluetoothd gets started when a user adds a bluetooth device to the system. To be clear, this isn't forcing bluetooth to be running all the time--- only when either of #1 or #2 are true. Signed-off-by: Ash Charles <ashcharles@gmail.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 3, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 3, 2015
The bluetooth.service runs bluetoothd to manage bluetooth devices, if present, in the system. By design, it should be running in either of two cases: 1. A userspace utility (e.g. networkmanager) has made a dbus request for bluetooth services provided by org.bluez. Even without this patch, the bluetooth.service gets run via dbus activation under the systmed aliased name 'dbus-org-bluez.service'. Perfect! 2. A bluetooth device is added to the system. When a bluetooth device is added, udev triggers the special systemd target, bluetooth.target intended to pull in any services needed for bluetooth linked under bluetooth.target.wants. Enable bluetooth.service so it gets linked under bluetooth.target.wants and bluetoothd gets started when a user adds a bluetooth device to the system. To be clear, this isn't forcing bluetooth to be running all the time--- only when either of #1 or #2 are true. Signed-off-by: Ash Charles <ashcharles@gmail.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 17, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 17, 2015
The bluetooth.service runs bluetoothd to manage bluetooth devices, if present, in the system. By design, it should be running in either of two cases: 1. A userspace utility (e.g. networkmanager) has made a dbus request for bluetooth services provided by org.bluez. Even without this patch, the bluetooth.service gets run via dbus activation under the systmed aliased name 'dbus-org-bluez.service'. Perfect! 2. A bluetooth device is added to the system. When a bluetooth device is added, udev triggers the special systemd target, bluetooth.target intended to pull in any services needed for bluetooth linked under bluetooth.target.wants. Enable bluetooth.service so it gets linked under bluetooth.target.wants and bluetoothd gets started when a user adds a bluetooth device to the system. To be clear, this isn't forcing bluetooth to be running all the time--- only when either of #1 or #2 are true. Signed-off-by: Ash Charles <ashcharles@gmail.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 18, 2015
The bluetooth.service runs bluetoothd to manage bluetooth devices, if present, in the system. By design, it should be running in either of two cases: 1. A userspace utility (e.g. networkmanager) has made a dbus request for bluetooth services provided by org.bluez. Even without this patch, the bluetooth.service gets run via dbus activation under the systmed aliased name 'dbus-org-bluez.service'. Perfect! 2. A bluetooth device is added to the system. When a bluetooth device is added, udev triggers the special systemd target, bluetooth.target intended to pull in any services needed for bluetooth linked under bluetooth.target.wants. Enable bluetooth.service so it gets linked under bluetooth.target.wants and bluetoothd gets started when a user adds a bluetooth device to the system. To be clear, this isn't forcing bluetooth to be running all the time--- only when either of #1 or #2 are true. Signed-off-by: Ash Charles <ashcharles@gmail.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 18, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 18, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 20, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 24, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 24, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 27, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Aug 31, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Sep 14, 2015
the patch comes from: https://bugs.launchpad.net/ubuntu/+source/netkit-telnet/+bug/507455 https://launchpadlibrarian.net/37882973/0001-telnetd-Fix-deadlock-on-cleanup.patch The cleanup function in telnetd is called both directly and on SIGCHLD signals. This, unfortunately, triggered a deadlock in eglibc 2.9 while running on a 2.6.31.11 kernel. What we were seeing is hangs like these: (gdb) bt #0 0xb7702424 in __kernel_vsyscall () #1 0xb7658e61 in __lll_lock_wait_private () from ./lib/libc.so.6 #2 0xb767e7b5 in _L_lock_15 () from ./lib/libc.so.6 #3 0xb767e6e0 in utmpname () from ./lib/libc.so.6 #4 0xb76bcde7 in logout () from ./lib/libutil.so.1 #5 0x0804c827 in cleanup () #6 <signal handler called> #7 0xb7702424 in __kernel_vsyscall () #8 0xb7641003 in __fcntl_nocancel () from ./lib/libc.so.6 #9 0xb767e0c3 in getutline_r_file () from ./lib/libc.so.6 #10 0xb767d675 in getutline_r () from ./lib/libc.so.6 #11 0xb76bce42 in logout () from ./lib/libutil.so.1 #12 0x0804c827 in cleanup () #13 0x0804a0b5 in telnet () #14 0x0804a9c3 in main () and what has happened here is that the user closes the telnet session via the escape character. This causes telnetd to call cleanup in frame the SIGCHLD signal is delivered while telnetd is executing cleanup. Telnetd then calls the signal handler for SIGCHLD, which is cleanup(). Ouch. The actual deadlock is in libc. getutline_r in frame #10 gets the __libc_utmp_lock lock, and utmpname above does the same thing in frame The fix registers the SIGCHLD handler as cleanup_sighandler, and makes cleanup disable the SIGCHLD signal before calling cleanup_sighandler. Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net> Signed-off-by: Li Wang <li.wang@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
|
Please read README and send patches to openembedded-devel@lists.openembedded.org for review. |
philb
pushed a commit
that referenced
this pull request
Jan 19, 2017
The previous build_with_updated_interfaces_of_linux_v4.8_and_above.patch does not alloc struct ahash_request before using it. This will cause the kernel call trace below when calling gen_scsiid on kernel 4.8 or later version. This patch normalizes the calling of ahash API according to the example in kernel doc Documentation/crypto/api-intro.txt. BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] PGD dd77067 PUD dd7c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: iscsi_trgt(O) CPU: 0 PID: 350 Comm: ietd Tainted: G O 4.8.12-yocto-standard #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 task: ffff88000dfe2c00 task.stack: ffff88000de88000 RIP: 0010:[<ffffffffa0008d45>] [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] RSP: 0018:ffff88000de8bd90 EFLAGS: 00000206 RAX: 000000000000ddfa RBX: ffff88000ddd1d78 RCX: ffffea0000000000 RDX: 0000000000000600 RSI: 0000000000000000 RDI: ffff88000ddd1c14 RBP: ffff88000de8be38 R08: ffff88000de44180 R09: ffff88000de8bdd0 R10: 000000000000002c R11: 0000000000000000 R12: ffff88000ddfa600 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88000de92200 FS: 00007f767548b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 000000000dd2d000 CR4: 00000000000006f0 Stack: ffff88000de8bdd0 ffff88000dc1b3d0 ffff88000ddfa650 ffff88000ddfa660 ffff88000df8f000 ffff88000ddd1c00 ffff88000de44180 0000000000000000 ffffea0000377440 0000000f00000c14 0000000000000000 0000000000000000 Call Trace: [<ffffffffa0006547>] ioctl+0x217/0x390 [iscsi_trgt] [<ffffffff81192574>] do_vfs_ioctl+0x94/0x5c0 [<ffffffff8117ff73>] ? vfs_read+0xf3/0x120 [<ffffffff81192b19>] SyS_ioctl+0x79/0x90 [<ffffffff8191a45b>] entry_SYSCALL_64_fastpath+0x13/0x8f Code: 4c 01 e0 0f 82 a2 01 00 00 48 b9 00 00 00 80 ff 77 00 00 48 01 c8 45 31 f6 48 b9 00 00 00 00 00 ea ff ff 89 54 24 68 48 c1 e8 0c <49> 8b 56 20 4c 89 44 24 20 4c 89 f7 48 c1 e0 06 c7 44 24 6c 04 RIP [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] RSP <ffff88000de8bd90> CR2: 0000000000000020 end trace cd2016297df21635 ] ietd_response_recv 200 0 -5 Input/output error. Signed-off-by: He Zhe <zhe.he@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Jan 25, 2017
The previous build_with_updated_interfaces_of_linux_v4.8_and_above.patch does not alloc struct ahash_request before using it. This will cause the kernel call trace below when calling gen_scsiid on kernel 4.8 or later version. This patch normalizes the calling of ahash API according to the example in kernel doc Documentation/crypto/api-intro.txt. BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] PGD dd77067 PUD dd7c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: iscsi_trgt(O) CPU: 0 PID: 350 Comm: ietd Tainted: G O 4.8.12-yocto-standard #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 task: ffff88000dfe2c00 task.stack: ffff88000de88000 RIP: 0010:[<ffffffffa0008d45>] [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] RSP: 0018:ffff88000de8bd90 EFLAGS: 00000206 RAX: 000000000000ddfa RBX: ffff88000ddd1d78 RCX: ffffea0000000000 RDX: 0000000000000600 RSI: 0000000000000000 RDI: ffff88000ddd1c14 RBP: ffff88000de8be38 R08: ffff88000de44180 R09: ffff88000de8bdd0 R10: 000000000000002c R11: 0000000000000000 R12: ffff88000ddfa600 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88000de92200 FS: 00007f767548b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 000000000dd2d000 CR4: 00000000000006f0 Stack: ffff88000de8bdd0 ffff88000dc1b3d0 ffff88000ddfa650 ffff88000ddfa660 ffff88000df8f000 ffff88000ddd1c00 ffff88000de44180 0000000000000000 ffffea0000377440 0000000f00000c14 0000000000000000 0000000000000000 Call Trace: [<ffffffffa0006547>] ioctl+0x217/0x390 [iscsi_trgt] [<ffffffff81192574>] do_vfs_ioctl+0x94/0x5c0 [<ffffffff8117ff73>] ? vfs_read+0xf3/0x120 [<ffffffff81192b19>] SyS_ioctl+0x79/0x90 [<ffffffff8191a45b>] entry_SYSCALL_64_fastpath+0x13/0x8f Code: 4c 01 e0 0f 82 a2 01 00 00 48 b9 00 00 00 80 ff 77 00 00 48 01 c8 45 31 f6 48 b9 00 00 00 00 00 ea ff ff 89 54 24 68 48 c1 e8 0c <49> 8b 56 20 4c 89 44 24 20 4c 89 f7 48 c1 e0 06 c7 44 24 6c 04 RIP [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] RSP <ffff88000de8bd90> CR2: 0000000000000020 end trace cd2016297df21635 ] ietd_response_recv 200 0 -5 Input/output error. Signed-off-by: He Zhe <zhe.he@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Jan 25, 2017
…initiator This patch fixes below inconsistent crash when trying to login to iSCSI target server, observed with linux kernel v4.1. -- snip -- CPU: 1 PID: 29883 Comm: istd1 Tainted: G O 4.1.35-rt40-yocto-standard #1 Hardware name: To be filled by O.E.M. To be filled by O.E.M./Larne CRB, BIOS 4.6.5.4 09/18/2014 task: ffff88020f1f30c0 ti: ffff8800d7f3c000 task.ti: ffff8800d7f3c000 RIP: 0010:[<ffffffff8140d1ae>] [<ffffffff8140d1ae>] copy_to_iter+0x3e/0x280 RSP: 0018:ffff8800d7f3f728 EFLAGS: 00010246 RAX: 00000000d7f3f928 RBX: 0000000000000030 RCX: 0000000000000030 RDX: ffff8800d7f3f900 RSI: 0000000000000030 RDI: ffff8800d1501e82 RBP: ffff8800d7f3f768 R08: 00000000c127d467 R09: 0000000000000000 R10: ffff88020f29e118 R11: 0000000000000004 R12: ffff8800d7f3f900 R13: 0000000000000030 R14: 0000000000000001 R15: 0000000000000246 FS: 00007f86f9c4c700(0000) GS:ffff88021ec80000(0000) knlGS:00000000f7733700 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000024e CR3: 00000000d38b0000 CR4: 00000000000406e0 Stack: ffff880214f14ec0 ffff8800d1501e82 ffff8800d7f3f748 0000000000000030 ffff88020f122500 0000000000000030 0000000000000000 0000000000000030 ffff8800d7f3f7c8 ffffffff81806981 ffff8800d7f3f798 ffffffff8105d72a Call Trace: [<ffffffff81806981>] skb_copy_datagram_iter+0x71/0x2b0 [<ffffffff8105d72a>] ? __local_bh_enable_ip+0x4a/0xb0 [<ffffffff8186c9c0>] tcp_recvmsg+0x5e0/0xbb0 [<ffffffff81898ded>] inet_recvmsg+0x8d/0xb0 [<ffffffff817f49f3>] sock_recvmsg+0x13/0x20 [<ffffffffa01655c3>] do_recv+0xe3/0x1f0 [iscsi_trgt] [<ffffffff81153097>] ? __mod_zone_page_state+0x77/0xb0 [<ffffffff81417613>] ? __this_cpu_preempt_check+0x13/0x20 [<ffffffff81153097>] ? __mod_zone_page_state+0x77/0xb0 [<ffffffff8140fed5>] ? find_next_bit+0x15/0x30 [<ffffffff813fa8e0>] ? cpumask_next_and+0x30/0x50 [<ffffffff8113f785>] ? __alloc_pages_nodemask+0x165/0x980 [<ffffffff8107e370>] ? preempt_count_add+0xd0/0xf0 [<ffffffff8195da8b>] ? _raw_spin_lock+0x1b/0x60 [<ffffffff8109cfa8>] ? cpuacct_charge+0x58/0x70 [<ffffffff81089039>] ? update_curr+0xb9/0x190 [<ffffffff81417613>] ? __this_cpu_preempt_check+0x13/0x20 [<ffffffff8112b43f>] ? __perf_event_task_sched_in+0x4f/0x90 [<ffffffff8195dbbd>] ? _raw_spin_unlock_irq+0x1d/0x40 [<ffffffff8107e223>] ? finish_task_switch+0x63/0xe0 [<ffffffff81959e3b>] ? __schedule+0x38b/0x980 [<ffffffff8107e370>] ? preempt_count_add+0xd0/0xf0 [<ffffffffa0165c65>] istd+0x4d5/0x1390 [iscsi_trgt] [<ffffffff81959e3b>] ? __schedule+0x38b/0x980 [<ffffffffa0165790>] ? nthread_wakeup+0x40/0x40 [iscsi_trgt] [<ffffffffa0165790>] ? nthread_wakeup+0x40/0x40 [iscsi_trgt] [<ffffffff8107748b>] kthread+0xbb/0xe0 [<ffffffff81950000>] ? wireless_dev_seq_show+0x100/0x180 [<ffffffff810773d0>] ? kthread_worker_fn+0x170/0x170 [<ffffffff8195e7a2>] ret_from_fork+0x42/0x70 [<ffffffff810773d0>] ? kthread_worker_fn+0x170/0x170 Code: 5a 10 48 89 7d c8 48 39 f3 48 0f 47 de 48 85 db 0f 84 6f 01 00 00 8b 02 49 89 d4 4c 8b 72 08 4c 8b 7a 18 a8 04 0f 85 a2 00 00 00 <4d> 8b 6f 08 4d 29 f5 49 39 dd 4c 0f 47 eb a8 02 0f 85 5c 01 00 RSP <ffff8800d7f3f728> CR2: 000000000000024e ------------[ cut here ]------------ -- snip -- The original patch is at http://launchpadlibrarian.net/218100509/iscsitarget_1.4.20.3+svn499-0ubuntu2_1.4.20.3+svn499-0ubuntu2.1.diff.gz, those changes were taken using #ifs, inorder to allow compilation of iscsitarget package with linux kernels < 3.19. Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Feb 6, 2017
The previous build_with_updated_interfaces_of_linux_v4.8_and_above.patch does not alloc struct ahash_request before using it. This will cause the kernel call trace below when calling gen_scsiid on kernel 4.8 or later version. This patch normalizes the calling of ahash API according to the example in kernel doc Documentation/crypto/api-intro.txt. BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] PGD dd77067 PUD dd7c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: iscsi_trgt(O) CPU: 0 PID: 350 Comm: ietd Tainted: G O 4.8.12-yocto-standard #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 task: ffff88000dfe2c00 task.stack: ffff88000de88000 RIP: 0010:[<ffffffffa0008d45>] [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] RSP: 0018:ffff88000de8bd90 EFLAGS: 00000206 RAX: 000000000000ddfa RBX: ffff88000ddd1d78 RCX: ffffea0000000000 RDX: 0000000000000600 RSI: 0000000000000000 RDI: ffff88000ddd1c14 RBP: ffff88000de8be38 R08: ffff88000de44180 R09: ffff88000de8bdd0 R10: 000000000000002c R11: 0000000000000000 R12: ffff88000ddfa600 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88000de92200 FS: 00007f767548b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 000000000dd2d000 CR4: 00000000000006f0 Stack: ffff88000de8bdd0 ffff88000dc1b3d0 ffff88000ddfa650 ffff88000ddfa660 ffff88000df8f000 ffff88000ddd1c00 ffff88000de44180 0000000000000000 ffffea0000377440 0000000f00000c14 0000000000000000 0000000000000000 Call Trace: [<ffffffffa0006547>] ioctl+0x217/0x390 [iscsi_trgt] [<ffffffff81192574>] do_vfs_ioctl+0x94/0x5c0 [<ffffffff8117ff73>] ? vfs_read+0xf3/0x120 [<ffffffff81192b19>] SyS_ioctl+0x79/0x90 [<ffffffff8191a45b>] entry_SYSCALL_64_fastpath+0x13/0x8f Code: 4c 01 e0 0f 82 a2 01 00 00 48 b9 00 00 00 80 ff 77 00 00 48 01 c8 45 31 f6 48 b9 00 00 00 00 00 ea ff ff 89 54 24 68 48 c1 e8 0c <49> 8b 56 20 4c 89 44 24 20 4c 89 f7 48 c1 e0 06 c7 44 24 6c 04 RIP [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] RSP <ffff88000de8bd90> CR2: 0000000000000020 end trace cd2016297df21635 ] ietd_response_recv 200 0 -5 Input/output error. Signed-off-by: He Zhe <zhe.he@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Feb 6, 2017
…initiator This patch fixes below inconsistent crash when trying to login to iSCSI target server, observed with linux kernel v4.1. -- snip -- CPU: 1 PID: 29883 Comm: istd1 Tainted: G O 4.1.35-rt40-yocto-standard #1 Hardware name: To be filled by O.E.M. To be filled by O.E.M./Larne CRB, BIOS 4.6.5.4 09/18/2014 task: ffff88020f1f30c0 ti: ffff8800d7f3c000 task.ti: ffff8800d7f3c000 RIP: 0010:[<ffffffff8140d1ae>] [<ffffffff8140d1ae>] copy_to_iter+0x3e/0x280 RSP: 0018:ffff8800d7f3f728 EFLAGS: 00010246 RAX: 00000000d7f3f928 RBX: 0000000000000030 RCX: 0000000000000030 RDX: ffff8800d7f3f900 RSI: 0000000000000030 RDI: ffff8800d1501e82 RBP: ffff8800d7f3f768 R08: 00000000c127d467 R09: 0000000000000000 R10: ffff88020f29e118 R11: 0000000000000004 R12: ffff8800d7f3f900 R13: 0000000000000030 R14: 0000000000000001 R15: 0000000000000246 FS: 00007f86f9c4c700(0000) GS:ffff88021ec80000(0000) knlGS:00000000f7733700 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000024e CR3: 00000000d38b0000 CR4: 00000000000406e0 Stack: ffff880214f14ec0 ffff8800d1501e82 ffff8800d7f3f748 0000000000000030 ffff88020f122500 0000000000000030 0000000000000000 0000000000000030 ffff8800d7f3f7c8 ffffffff81806981 ffff8800d7f3f798 ffffffff8105d72a Call Trace: [<ffffffff81806981>] skb_copy_datagram_iter+0x71/0x2b0 [<ffffffff8105d72a>] ? __local_bh_enable_ip+0x4a/0xb0 [<ffffffff8186c9c0>] tcp_recvmsg+0x5e0/0xbb0 [<ffffffff81898ded>] inet_recvmsg+0x8d/0xb0 [<ffffffff817f49f3>] sock_recvmsg+0x13/0x20 [<ffffffffa01655c3>] do_recv+0xe3/0x1f0 [iscsi_trgt] [<ffffffff81153097>] ? __mod_zone_page_state+0x77/0xb0 [<ffffffff81417613>] ? __this_cpu_preempt_check+0x13/0x20 [<ffffffff81153097>] ? __mod_zone_page_state+0x77/0xb0 [<ffffffff8140fed5>] ? find_next_bit+0x15/0x30 [<ffffffff813fa8e0>] ? cpumask_next_and+0x30/0x50 [<ffffffff8113f785>] ? __alloc_pages_nodemask+0x165/0x980 [<ffffffff8107e370>] ? preempt_count_add+0xd0/0xf0 [<ffffffff8195da8b>] ? _raw_spin_lock+0x1b/0x60 [<ffffffff8109cfa8>] ? cpuacct_charge+0x58/0x70 [<ffffffff81089039>] ? update_curr+0xb9/0x190 [<ffffffff81417613>] ? __this_cpu_preempt_check+0x13/0x20 [<ffffffff8112b43f>] ? __perf_event_task_sched_in+0x4f/0x90 [<ffffffff8195dbbd>] ? _raw_spin_unlock_irq+0x1d/0x40 [<ffffffff8107e223>] ? finish_task_switch+0x63/0xe0 [<ffffffff81959e3b>] ? __schedule+0x38b/0x980 [<ffffffff8107e370>] ? preempt_count_add+0xd0/0xf0 [<ffffffffa0165c65>] istd+0x4d5/0x1390 [iscsi_trgt] [<ffffffff81959e3b>] ? __schedule+0x38b/0x980 [<ffffffffa0165790>] ? nthread_wakeup+0x40/0x40 [iscsi_trgt] [<ffffffffa0165790>] ? nthread_wakeup+0x40/0x40 [iscsi_trgt] [<ffffffff8107748b>] kthread+0xbb/0xe0 [<ffffffff81950000>] ? wireless_dev_seq_show+0x100/0x180 [<ffffffff810773d0>] ? kthread_worker_fn+0x170/0x170 [<ffffffff8195e7a2>] ret_from_fork+0x42/0x70 [<ffffffff810773d0>] ? kthread_worker_fn+0x170/0x170 Code: 5a 10 48 89 7d c8 48 39 f3 48 0f 47 de 48 85 db 0f 84 6f 01 00 00 8b 02 49 89 d4 4c 8b 72 08 4c 8b 7a 18 a8 04 0f 85 a2 00 00 00 <4d> 8b 6f 08 4d 29 f5 49 39 dd 4c 0f 47 eb a8 02 0f 85 5c 01 00 RSP <ffff8800d7f3f728> CR2: 000000000000024e ------------[ cut here ]------------ -- snip -- The original patch is at http://launchpadlibrarian.net/218100509/iscsitarget_1.4.20.3+svn499-0ubuntu2_1.4.20.3+svn499-0ubuntu2.1.diff.gz, those changes were taken using #ifs, inorder to allow compilation of iscsitarget package with linux kernels < 3.19. Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
philb
pushed a commit
that referenced
this pull request
Feb 13, 2017
The previous build_with_updated_interfaces_of_linux_v4.8_and_above.patch does not alloc struct ahash_request before using it. This will cause the kernel call trace below when calling gen_scsiid on kernel 4.8 or later version. This patch normalizes the calling of ahash API according to the example in kernel doc Documentation/crypto/api-intro.txt. BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] PGD dd77067 PUD dd7c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: iscsi_trgt(O) CPU: 0 PID: 350 Comm: ietd Tainted: G O 4.8.12-yocto-standard #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 task: ffff88000dfe2c00 task.stack: ffff88000de88000 RIP: 0010:[<ffffffffa0008d45>] [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] RSP: 0018:ffff88000de8bd90 EFLAGS: 00000206 RAX: 000000000000ddfa RBX: ffff88000ddd1d78 RCX: ffffea0000000000 RDX: 0000000000000600 RSI: 0000000000000000 RDI: ffff88000ddd1c14 RBP: ffff88000de8be38 R08: ffff88000de44180 R09: ffff88000de8bdd0 R10: 000000000000002c R11: 0000000000000000 R12: ffff88000ddfa600 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88000de92200 FS: 00007f767548b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 000000000dd2d000 CR4: 00000000000006f0 Stack: ffff88000de8bdd0 ffff88000dc1b3d0 ffff88000ddfa650 ffff88000ddfa660 ffff88000df8f000 ffff88000ddd1c00 ffff88000de44180 0000000000000000 ffffea0000377440 0000000f00000c14 0000000000000000 0000000000000000 Call Trace: [<ffffffffa0006547>] ioctl+0x217/0x390 [iscsi_trgt] [<ffffffff81192574>] do_vfs_ioctl+0x94/0x5c0 [<ffffffff8117ff73>] ? vfs_read+0xf3/0x120 [<ffffffff81192b19>] SyS_ioctl+0x79/0x90 [<ffffffff8191a45b>] entry_SYSCALL_64_fastpath+0x13/0x8f Code: 4c 01 e0 0f 82 a2 01 00 00 48 b9 00 00 00 80 ff 77 00 00 48 01 c8 45 31 f6 48 b9 00 00 00 00 00 ea ff ff 89 54 24 68 48 c1 e8 0c <49> 8b 56 20 4c 89 44 24 20 4c 89 f7 48 c1 e0 06 c7 44 24 6c 04 RIP [<ffffffffa0008d45>] volume_add+0x625/0x7f0 [iscsi_trgt] RSP <ffff88000de8bd90> CR2: 0000000000000020 end trace cd2016297df21635 ] ietd_response_recv 200 0 -5 Input/output error. Signed-off-by: He Zhe <zhe.he@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
kraj
added a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Jun 9, 2021
Fixes patching file tests/test_functionality.py Hunk openembedded#1 FAILED at 5 (different line endings). 1 out of 1 hunk FAILED -- rejects in file tests/test_functionality.py Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
added a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Jun 9, 2021
Fixes patching file tests/test_functionality.py Hunk openembedded#1 FAILED at 5 (different line endings). 1 out of 1 hunk FAILED -- rejects in file tests/test_functionality.py Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Aug 9, 2021
After changing image_types_sparse to follow new override syntax, using this class generates the syntax error, because CONVERSION_CMD:sparse() function is added to the generated shell file, but color can not be a part of the function name. Rewrite it to be the variable rather than the function, so that it does not end up the run.do_image_FOO file. DEBUG: Executing shell function do_image_ext4 [.......]/temp/run.do_image_ext4.1247938: line 184: `CONVERSION_CMD:sparse': not a valid identifier WARNING: [.......]/temp/run.do_image_ext4.1247938:151 exit 2 from 'export systemd_user_unitdir="/usr/lib/systemd/user"' WARNING: Backtrace (BB generated script): openembedded#1: main, [.......]/temp/run.do_image_ext4.1247938, line 151 ERROR: Execution of '[.......]/temp/run.do_image_ext4.1247938' failed with exit code 2: [.......]/temp/run.do_image_ext4.1247938: line 184: `CONVERSION_CMD:sparse': not a valid identifier WARNING: [.......]/temp/run.do_image_ext4.1247938:151 exit 2 from 'export systemd_user_unitdir="/usr/lib/systemd/user"' WARNING: Backtrace (BB generated script): openembedded#1: main, [.......]/temp/run.do_image_ext4.1247938, line 151 Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Dec 2, 2021
The original fix for team_basic_test.py only change the interpreter to python3, but still some error as below: # ./run-ptest File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 35 print "Usage: team_basic_test.py [OPTION...]" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? # ./run-ptest RUN openembedded#1 # "ip link add testteamx type team" # "teamnl testteamx getoption mode" # "ip link del testteamx" # "modprobe -r team_mode_loadbalance team_mode_roundrobin team_mode_activebackup team_mode_broadcast team" Traceback (most recent call last): File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 206, in <module> main() File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 203, in main btest.run() File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 180, in run self._run_one_loop(i + 1) File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 173, in _run_one_loop self._run_one_mode(mode_name) File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 101, in _run_one_mode cmd_exec("teamnl %s getoption mode" % team_name, "*NOMODE*") File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 80, in cmd_exec raise CmdExecUnexpectedOutputException(output, expected_output) __main__.CmdExecUnexpectedOutputException: Command execution output unexpected: "b'*NOMODE*'" != "*NOMODE*" So rework team_basic_test.py to fix the above issue. Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Dec 27, 2021
The original fix for team_basic_test.py only change the interpreter to python3, but still some error as below: # ./run-ptest File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 35 print "Usage: team_basic_test.py [OPTION...]" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? # ./run-ptest RUN #1 # "ip link add testteamx type team" # "teamnl testteamx getoption mode" # "ip link del testteamx" # "modprobe -r team_mode_loadbalance team_mode_roundrobin team_mode_activebackup team_mode_broadcast team" Traceback (most recent call last): File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 206, in <module> main() File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 203, in main btest.run() File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 180, in run self._run_one_loop(i + 1) File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 173, in _run_one_loop self._run_one_mode(mode_name) File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 101, in _run_one_mode cmd_exec("teamnl %s getoption mode" % team_name, "*NOMODE*") File "/usr/lib64/libteam/ptest/./team_basic_test.py", line 80, in cmd_exec raise CmdExecUnexpectedOutputException(output, expected_output) __main__.CmdExecUnexpectedOutputException: Command execution output unexpected: "b'*NOMODE*'" != "*NOMODE*" So rework team_basic_test.py to fix the above issue. Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Armin Kuster <akuster808@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Mar 8, 2022
Fixes: WARNING: lib32-redis-7.0-rc1-r0 do_patch: Fuzz detected: Applying patch GNU_SOURCE.patch patching file src/zmalloc.c Hunk openembedded#1 succeeded at 32 with fuzz 2 (offset 4 lines). Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Mar 8, 2022
Fixes: WARNING: lib32-redis-7.0-rc1-r0 do_patch: Fuzz detected: Applying patch GNU_SOURCE.patch patching file src/zmalloc.c Hunk openembedded#1 succeeded at 32 with fuzz 2 (offset 4 lines). Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 9, 2022
Fixes: WARNING: lib32-redis-7.0-rc1-r0 do_patch: Fuzz detected: Applying patch GNU_SOURCE.patch patching file src/zmalloc.c Hunk #1 succeeded at 32 with fuzz 2 (offset 4 lines). Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 27, 2022
Applying patch CVE-2021-22570.patch patching file src/google/protobuf/descriptor.cc Hunk #1 succeeded at 2603 with fuzz 1 (offset -23 lines). Hunk #2 succeeded at 2817 with fuzz 1 (offset -14 lines). Hunk #3 succeeded at 4006 (offset -17 lines). Hunk #4 succeeded at 4050 (offset -18 lines). Hunk #5 succeeded at 4368 (offset -18 lines). Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Armin Kuster <akuster808@gmail.com>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/meta-openembedded
that referenced
this pull request
Mar 28, 2022
Source: meta-openembedded MR: 115838 Type: Integration Disposition: Merged from meta-openembedded ChangeID: a14eb5e Description: Applying patch CVE-2021-22570.patch patching file src/google/protobuf/descriptor.cc Hunk openembedded#1 succeeded at 2603 with fuzz 1 (offset -23 lines). Hunk openembedded#2 succeeded at 2817 with fuzz 1 (offset -14 lines). Hunk openembedded#3 succeeded at 4006 (offset -17 lines). Hunk openembedded#4 succeeded at 4050 (offset -18 lines). Hunk openembedded#5 succeeded at 4368 (offset -18 lines). Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
halstead
pushed a commit
that referenced
this pull request
Apr 18, 2022
Commit 17e931e ("polkit: fix CVE-2021-3560") contains - upstream commit a04d13affe0fa53ff618e07aa8f57f4c0e3b9b81 Commit 67ec3e0 ("polkit: Fix for CVE-2021-4115") contains both: - upstream commit a04d13affe0fa53ff618e07aa8f57f4c0e3b9b81 (CVE-2021-3560) - upstream commit 41cb093f554da8772362654a128a84dd8a5542a7 (CVE-2021-4115) Thus the fix for CVE-2021-3560 is applied twice, resulting in warnings during do_patch. Curiously it neither fails nor complains about patch already applied. Also devtool silently discards the duplicate patch. Drop the duplicate patch, to resolve following warnings: WARNING: polkit-0.116-r0 do_patch: Fuzz detected: Applying patch 0001-GHSL-2021-074-authentication-bypass-vulnerability-in.patch patching file src/polkit/polkitsystembusname.c Hunk #1 succeeded at 438 with fuzz 2 (offset 3 lines). Applying patch CVE-2021-4115.patch patching file src/polkit/polkitsystembusname.c Hunk #4 succeeded at 439 with fuzz 2. Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org> Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
May 26, 2022
Applying patch CVE-2021-22570.patch patching file src/google/protobuf/descriptor.cc Hunk #1 succeeded at 2603 with fuzz 1 (offset -23 lines). Hunk #2 succeeded at 2817 with fuzz 1 (offset -14 lines). Hunk #3 succeeded at 4006 (offset -17 lines). Hunk #4 succeeded at 4050 (offset -18 lines). Hunk #5 succeeded at 4368 (offset -18 lines). Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
May 26, 2022
Commit 17e931e ("polkit: fix CVE-2021-3560") contains - upstream commit a04d13affe0fa53ff618e07aa8f57f4c0e3b9b81 Commit 67ec3e0 ("polkit: Fix for CVE-2021-4115") contains both: - upstream commit a04d13affe0fa53ff618e07aa8f57f4c0e3b9b81 (CVE-2021-3560) - upstream commit 41cb093f554da8772362654a128a84dd8a5542a7 (CVE-2021-4115) Thus the fix for CVE-2021-3560 is applied twice, resulting in warnings during do_patch. Curiously it neither fails nor complains about patch already applied. Also devtool silently discards the duplicate patch. Drop the duplicate patch, to resolve following warnings: WARNING: polkit-0.116-r0 do_patch: Fuzz detected: Applying patch 0001-GHSL-2021-074-authentication-bypass-vulnerability-in.patch patching file src/polkit/polkitsystembusname.c Hunk #1 succeeded at 438 with fuzz 2 (offset 3 lines). Applying patch CVE-2021-4115.patch patching file src/polkit/polkitsystembusname.c Hunk #4 succeeded at 439 with fuzz 2. Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org> Signed-off-by: Armin Kuster <akuster808@gmail.com>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/meta-openembedded
that referenced
this pull request
Jun 3, 2022
Source: meta-openembedded MR: 118244 Type: Integration Disposition: Merged from meta-openembedded ChangeID: aa316ee Description: Commit 17e931e ("polkit: fix CVE-2021-3560") contains - upstream commit a04d13affe0fa53ff618e07aa8f57f4c0e3b9b81 Commit 67ec3e0 ("polkit: Fix for CVE-2021-4115") contains both: - upstream commit a04d13affe0fa53ff618e07aa8f57f4c0e3b9b81 (CVE-2021-3560) - upstream commit 41cb093f554da8772362654a128a84dd8a5542a7 (CVE-2021-4115) Thus the fix for CVE-2021-3560 is applied twice, resulting in warnings during do_patch. Curiously it neither fails nor complains about patch already applied. Also devtool silently discards the duplicate patch. Drop the duplicate patch, to resolve following warnings: WARNING: polkit-0.116-r0 do_patch: Fuzz detected: Applying patch 0001-GHSL-2021-074-authentication-bypass-vulnerability-in.patch patching file src/polkit/polkitsystembusname.c Hunk openembedded#1 succeeded at 438 with fuzz 2 (offset 3 lines). Applying patch CVE-2021-4115.patch patching file src/polkit/polkitsystembusname.c Hunk openembedded#4 succeeded at 439 with fuzz 2. Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Aug 12, 2022
Fix: WARNING: lib32-redis-7.0.4-r0 do_patch: Fuzz detected: Applying patch GNU_SOURCE.patch patching file src/zmalloc.c Hunk openembedded#1 succeeded at 32 with fuzz 2 (offset 4 lines). There are two version of redis, and need different GNU_SOURCE.patch Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Aug 15, 2022
Fix: WARNING: lib32-redis-7.0.4-r0 do_patch: Fuzz detected: Applying patch GNU_SOURCE.patch patching file src/zmalloc.c Hunk openembedded#1 succeeded at 32 with fuzz 2 (offset 4 lines). There are two version of redis, and need different GNU_SOURCE.patch Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Sep 5, 2022
Fix the following warning: WARNING: polkit-0.119-r0 do_patch: Fuzz detected: Applying patch 0004-Make-netgroup-support-optional.patch patching file configure.ac Hunk openembedded#1 succeeded at 117 with fuzz 2 (offset 17 lines). patching file meson.build patching file src/polkit/polkitidentity.c patching file src/polkit/polkitunixnetgroup.c patching file src/polkitbackend/polkitbackendinteractiveauthority.c patching file src/polkitbackend/polkitbackendjsauthority.cpp Hunk openembedded#1 succeeded at 1291 (offset -233 lines). Hunk openembedded#2 succeeded at 1306 (offset -233 lines). patching file test/polkit/polkitidentitytest.c patching file test/polkit/polkitunixnetgrouptest.c patching file test/polkitbackend/test-polkitbackendjsauthority.c Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Sep 6, 2022
Fix the following warning: WARNING: polkit-0.119-r0 do_patch: Fuzz detected: Applying patch 0004-Make-netgroup-support-optional.patch patching file configure.ac Hunk openembedded#1 succeeded at 117 with fuzz 2 (offset 17 lines). patching file meson.build patching file src/polkit/polkitidentity.c patching file src/polkit/polkitunixnetgroup.c patching file src/polkitbackend/polkitbackendinteractiveauthority.c patching file src/polkitbackend/polkitbackendjsauthority.cpp Hunk openembedded#1 succeeded at 1291 (offset -233 lines). Hunk openembedded#2 succeeded at 1306 (offset -233 lines). patching file test/polkit/polkitidentitytest.c patching file test/polkit/polkitunixnetgrouptest.c patching file test/polkitbackend/test-polkitbackendjsauthority.c Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
halstead
pushed a commit
that referenced
this pull request
May 14, 2023
Fix: WARNING: lib32-redis-7.0.4-r0 do_patch: Fuzz detected: Applying patch GNU_SOURCE.patch patching file src/zmalloc.c Hunk #1 succeeded at 32 with fuzz 2 (offset 4 lines). There are two version of redis, and need different GNU_SOURCE.patch Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Armin Kuster <akuster808@gmail.com>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/meta-openembedded
that referenced
this pull request
May 15, 2023
Source: meta-openembedded MR: 126092 Type: Integration Disposition: Merged from meta-openembedded ChangeID: 3deca45 Description: Fix: WARNING: lib32-redis-7.0.4-r0 do_patch: Fuzz detected: Applying patch GNU_SOURCE.patch patching file src/zmalloc.c Hunk openembedded#1 succeeded at 32 with fuzz 2 (offset 4 lines). There are two version of redis, and need different GNU_SOURCE.patch Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
kraj
added a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Nov 17, 2023
This was resulting on rejects on master patching file modules/juce_core/system/juce_StandardHeader.h Hunk openembedded#1 FAILED at 64 (different line endings). 1 out of 1 hunk FAILED -- rejects in file modules/juce_core/system/juce_StandardHeader.h Patch 0001-StandardHeader-Include-utility-for-GCC-12-compatibil.patch does not apply (enforce with -f) Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Yoann Congal <yoann.congal@smile.fr>
kraj
added a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Nov 17, 2023
This was resulting on rejects on master patching file modules/juce_core/system/juce_StandardHeader.h Hunk openembedded#1 FAILED at 64 (different line endings). 1 out of 1 hunk FAILED -- rejects in file modules/juce_core/system/juce_StandardHeader.h Patch 0001-StandardHeader-Include-utility-for-GCC-12-compatibil.patch does not apply (enforce with -f) Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Yoann Congal <yoann.congal@smile.fr>
kraj
added a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
Nov 17, 2023
This was resulting on rejects on master patching file modules/juce_core/system/juce_StandardHeader.h Hunk openembedded#1 FAILED at 64 (different line endings). 1 out of 1 hunk FAILED -- rejects in file modules/juce_core/system/juce_StandardHeader.h Patch 0001-StandardHeader-Include-utility-for-GCC-12-compatibil.patch does not apply (enforce with -f) Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Yoann Congal <yoann.congal@smile.fr>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
May 9, 2024
In particular, make it build with gcc 14. Changelog: d20bea4 xlsfonts 1.0.8 71d8e89 Use reallocarray() if available 2b9d8f5 Fix -Wincompatible-pointer-types warning from gcc (issue openembedded#1) e53bf74 gitlab CI: stop requiring Signed-off-by in commits 314d802 man page: emphasize this program is for querying an X server Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
May 10, 2024
In particular, make it build with gcc 14. Changelog: d20bea4 xlsfonts 1.0.8 71d8e89 Use reallocarray() if available 2b9d8f5 Fix -Wincompatible-pointer-types warning from gcc (issue openembedded#1) e53bf74 gitlab CI: stop requiring Signed-off-by in commits 314d802 man page: emphasize this program is for querying an X server Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
May 12, 2024
In particular, make it build with gcc 14. Changelog: d20bea4 xlsfonts 1.0.8 71d8e89 Use reallocarray() if available 2b9d8f5 Fix -Wincompatible-pointer-types warning from gcc (issue openembedded#1) e53bf74 gitlab CI: stop requiring Signed-off-by in commits 314d802 man page: emphasize this program is for querying an X server Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
May 28, 2024
devmapper update also updated lvm2. Thus build fails with: patching file daemons/lvmdbusd/utils.py Hunk openembedded#1 FAILED at 778. 1 out of 1 hunk FAILED -- rejects in file daemons/lvmdbusd/utils.py - Drop the submitted patch - Move PV to lvm2.inc to ensure we keep it in sync for libdevmapper and lvm2 - refresh patches Signed-off-by: Markus Volk <f_l_k@t-online.de> Signed-off-by: Khem Raj <raj.khem@gmail.com>
kraj
pushed a commit
to YoeDistro/meta-openembedded
that referenced
this pull request
May 28, 2024
devmapper update also updated lvm2. Thus build fails with: patching file daemons/lvmdbusd/utils.py Hunk openembedded#1 FAILED at 778. 1 out of 1 hunk FAILED -- rejects in file daemons/lvmdbusd/utils.py - Drop the submitted patch - Move PV to lvm2.inc to ensure we keep it in sync for libdevmapper and lvm2 - refresh patches Signed-off-by: Markus Volk <f_l_k@t-online.de> Signed-off-by: Khem Raj <raj.khem@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Sep 22, 2024
Starting with Linux 6.6, RDCYCLE is a privileged instruction on RISC-V and can't be used directly from userland. This causes 'systemctl start mysqld.service' failed with error: [ 1456.918172] mariadbd[12115]: unhandled signal 4 code 0x1 at 0x000055558689d134 in mariadbd[555585bfa000+14a7000] [ 1456.921772] CPU: 1 PID: 12115 Comm: mariadbd Not tainted 6.6.43-yocto-standard #1 [ 1456.922327] Hardware name: riscv-virtio,qemu (DT) [ 1456.923045] epc : 000055558689d134 ra : 000055558620ea48 sp : 00007fffdc487770 [ 1456.923525] gp : 00005555872ec400 tp : 00007fff89560780 t0 : 0000555587be32e8 [ 1456.923951] t1 : 0000555586886042 t2 : 000000002d6a89f0 s0 : 00007fffdc4877b0 Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Armin Kuster <akuster808@gmail.com>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/meta-openembedded
that referenced
this pull request
Oct 1, 2024
Source: meta-openembedded MR: 166941 Type: Integration Disposition: Merged from meta-openembedded ChangeID: e5c0a0b Description: Starting with Linux 6.6, RDCYCLE is a privileged instruction on RISC-V and can't be used directly from userland. This causes 'systemctl start mysqld.service' failed with error: [ 1456.918172] mariadbd[12115]: unhandled signal 4 code 0x1 at 0x000055558689d134 in mariadbd[555585bfa000+14a7000] [ 1456.921772] CPU: 1 PID: 12115 Comm: mariadbd Not tainted 6.6.43-yocto-standard openembedded#1 [ 1456.922327] Hardware name: riscv-virtio,qemu (DT) [ 1456.923045] epc : 000055558689d134 ra : 000055558620ea48 sp : 00007fffdc487770 [ 1456.923525] gp : 00005555872ec400 tp : 00007fff89560780 t0 : 0000555587be32e8 [ 1456.923951] t1 : 0000555586886042 t2 : 000000002d6a89f0 s0 : 00007fffdc4877b0 Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
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.
Added the make_scripts task to the ltp-ddt bitbake recipe.
If no task has created the kernel scripts before ltp-ddt is run, there is a compile error complaining that it cannot find scripts/basic/fixdep. This patch ensures that these scripts are built before compiling starts.