ltp-ddt sometimes cannot find scripts/basic/fixdep#1
Closed
ashleysommer wants to merge 1 commit intoopenembedded:masterfrom
ashleysommer:master
Closed
ltp-ddt sometimes cannot find scripts/basic/fixdep#1ashleysommer wants to merge 1 commit intoopenembedded:masterfrom ashleysommer:master
ashleysommer wants to merge 1 commit intoopenembedded:masterfrom
ashleysommer:master
Conversation
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>
Contributor
|
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>
philb
pushed a commit
that referenced
this pull request
Feb 20, 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 22, 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 22, 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 22, 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> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
philb
pushed a commit
that referenced
this pull request
Feb 22, 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> Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
halstead
pushed a commit
that referenced
this pull request
Mar 18, 2018
WARNING: glibmm-2.54.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch remove-examples.patch
patching file Makefile.am
patching file configure.ac
Hunk #1 succeeded at 166 with fuzz 1 (offset 30 lines).
Now at patch remove-examples.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 18, 2018
WARNING: gperftools-2.6.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch 0001-Support-Atomic-ops-on-clang.patch
patching file src/base/atomicops.h
Hunk #1 succeeded at 124 with fuzz 2 (offset 6 lines).
Now at patch 0001-Support-Atomic-ops-on-clang.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 18, 2018
WARNING: tcpdump-4.9.2-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch unnecessary-to-check-libpcap.patch
patching file configure.in
Hunk #1 succeeded at 418 with fuzz 2 (offset -149 lines).
Now at patch unnecessary-to-check-libpcap.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 18, 2018
WARNING: ntp-4.2.8p10-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch ntp-4.2.4_p6-nano.patch
patching file include/ntp_syscall.h
Hunk #1 succeeded at 10 with fuzz 2 (offset -4 lines).
Now at patch ntp-4.2.4_p6-nano.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 22, 2018
WARNING: glibmm-2.54.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch remove-examples.patch
patching file Makefile.am
patching file configure.ac
Hunk #1 succeeded at 166 with fuzz 1 (offset 30 lines).
Now at patch remove-examples.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 22, 2018
WARNING: gperftools-2.6.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch 0001-Support-Atomic-ops-on-clang.patch
patching file src/base/atomicops.h
Hunk #1 succeeded at 124 with fuzz 2 (offset 6 lines).
Now at patch 0001-Support-Atomic-ops-on-clang.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 22, 2018
WARNING: tcpdump-4.9.2-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch unnecessary-to-check-libpcap.patch
patching file configure.in
Hunk #1 succeeded at 418 with fuzz 2 (offset -149 lines).
Now at patch unnecessary-to-check-libpcap.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 22, 2018
WARNING: ntp-4.2.8p10-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch ntp-4.2.4_p6-nano.patch
patching file include/ntp_syscall.h
Hunk #1 succeeded at 10 with fuzz 2 (offset -4 lines).
Now at patch ntp-4.2.4_p6-nano.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 30, 2018
WARNING: tcpdump-4.9.2-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch unnecessary-to-check-libpcap.patch
patching file configure.in
Hunk #1 succeeded at 418 with fuzz 2 (offset -149 lines).
Now at patch unnecessary-to-check-libpcap.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Mar 30, 2018
WARNING: ntp-4.2.8p10-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch ntp-4.2.4_p6-nano.patch
patching file include/ntp_syscall.h
Hunk #1 succeeded at 10 with fuzz 2 (offset -4 lines).
Now at patch ntp-4.2.4_p6-nano.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
Fix QA warning:
WARNING: python-m2crypto-native-0.26.4-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch
0001-setup.py-link-in-sysroot-not-in-host-directories.patch
patching file setup.py
Hunk #1 succeeded at 127 with fuzz 1 (offset 65 lines).
Hunk #2 succeeded at 143 (offset 68 lines).
Now at patch 0001-setup.py-link-in-sysroot-not-in-host-directories.patch
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
WARNING: smbnetfs-git-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch Using-PKG_CHECK_MODULES-to-found-headers-and-libraries.patch
patching file configure.ac
Hunk #1 succeeded at 119 with fuzz 2 (offset -6 lines).
patching file src/Makefile.am
Hunk #1 succeeded at 17 (offset 1 line).
Now at patch Using-PKG_CHECK_MODULES-to-found-headers-and-libraries.patch
Signed-off-by: Hains van den Bosch <hainsvdbosch@ziggo.nl>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
WARNING: iperf3-3.2-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch 0001-include-stdint.h-for-various-std-c99-int-types.patch
patching file src/cjson.h
Hunk #1 succeeded at 28 with fuzz 2 (offset 5 lines).
patching file src/timer.h
Now at patch 0001-include-stdint.h-for-various-std-c99-int-types.patch
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
fixes
WARNING: efivar-0.31-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch allow-multi-definitions-for-native.patch
patching file Make.rules
Hunk #1 succeeded at 20 with fuzz 2.
Now at patch allow-multi-definitions-for-native.patch
Now at patch 0003-efivar-fix-for-cross-compile.patch
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
Fixes:
WARNING: augeas-1.5.0-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch sepbuildfix.patch
patching file Makefile.am
Hunk #1 succeeded at 5 with fuzz 2.
Now at patch sepbuildfix.patch
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
WARNING: pidgin-2.12.0-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch sanitize-configure.ac.patch
patching file configure.ac
Hunk #1 succeeded at 642 with fuzz 1 (offset 170 lines).
Hunk #2 succeeded at 2397 (offset 537 lines).
Hunk #3 succeeded at 2429 (offset 537 lines).
Now at patch sanitize-configure.ac.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
Fix QA warning:
WARNING: python-m2crypto-native-0.26.4-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch
0001-setup.py-link-in-sysroot-not-in-host-directories.patch
patching file setup.py
Hunk #1 succeeded at 127 with fuzz 1 (offset 65 lines).
Hunk #2 succeeded at 143 (offset 68 lines).
Now at patch 0001-setup.py-link-in-sysroot-not-in-host-directories.patch
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
WARNING: smbnetfs-git-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch Using-PKG_CHECK_MODULES-to-found-headers-and-libraries.patch
patching file configure.ac
Hunk #1 succeeded at 119 with fuzz 2 (offset -6 lines).
patching file src/Makefile.am
Hunk #1 succeeded at 17 (offset 1 line).
Now at patch Using-PKG_CHECK_MODULES-to-found-headers-and-libraries.patch
Signed-off-by: Hains van den Bosch <hainsvdbosch@ziggo.nl>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
WARNING: iperf3-3.2-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch 0001-include-stdint.h-for-various-std-c99-int-types.patch
patching file src/cjson.h
Hunk #1 succeeded at 28 with fuzz 2 (offset 5 lines).
patching file src/timer.h
Now at patch 0001-include-stdint.h-for-various-std-c99-int-types.patch
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
fixes
WARNING: efivar-0.31-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch allow-multi-definitions-for-native.patch
patching file Make.rules
Hunk #1 succeeded at 20 with fuzz 2.
Now at patch allow-multi-definitions-for-native.patch
Now at patch 0003-efivar-fix-for-cross-compile.patch
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
Fixes:
WARNING: augeas-1.5.0-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch sepbuildfix.patch
patching file Makefile.am
Hunk #1 succeeded at 5 with fuzz 2.
Now at patch sepbuildfix.patch
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
WARNING: pidgin-2.12.0-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to
incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch sanitize-configure.ac.patch
patching file configure.ac
Hunk #1 succeeded at 642 with fuzz 1 (offset 170 lines).
Hunk #2 succeeded at 2397 (offset 537 lines).
Hunk #3 succeeded at 2429 (offset 537 lines).
Now at patch sanitize-configure.ac.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
WARNING: tcpdump-4.9.2-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch unnecessary-to-check-libpcap.patch
patching file configure.in
Hunk #1 succeeded at 418 with fuzz 2 (offset -149 lines).
Now at patch unnecessary-to-check-libpcap.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
halstead
pushed a commit
that referenced
this pull request
Apr 9, 2018
WARNING: ntp-4.2.8p10-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch ntp-4.2.4_p6-nano.patch
patching file include/ntp_syscall.h
Hunk #1 succeeded at 10 with fuzz 2 (offset -4 lines).
Now at patch ntp-4.2.4_p6-nano.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Closed
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.