Searched hist:2061 (Results 1 - 25 of 41) sorted by relevance
/linux-master/Documentation/translations/ | ||
H A D | index.rst | diff f7ebe6b7 Tue May 25 09:25:39 MDT 2021 Akira Yokosawa <akiyks@gmail.com> docs: Activate exCJK only in CJK chapters Activating xeCJK in English and Italian-translation documents results in sub-optimal typesetting with wide-looking apostrophes and quotation marks. The xeCJK package provides macros for enabling and disabling its effect in the middle of a document, namely \makexeCJKactive and \makexeCJKinactive. So the goal of this change is to activate xeCJK in the relevant chapters in translations. To do this: o Define custom macros in the preamble depending on the availability of the "Noto Sans CJK" font so that those macros can be used regardless of the use of xeCJK package. o Patch \sphinxtableofcontents so that xeCJK is inactivated after table of contents. o Embed those custom macros in each language's index.rst file as a ".. raw:: latex" construct. Note: A CJK chapter needs \kerneldocCJKon in front of its chapter heading, while a non-CJK chapter should have \kerneldocCJKoff below its chapter heading. This is to make sure the CJK font is available to CJK chapter's heading and ending page's footer. Tested against Sphinx versions 2.4.4 and 4.0.2. Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Tested-by: Wu XiangCheng <bobwxc@email.cn> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/lkml/2061da0a-6ab1-35f3-99c1-dbc415444f37@gmail.com Link: https://lore.kernel.org/r/83208ddc-5de9-b283-3fd6-92c635348ca0@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net> |
/linux-master/Documentation/translations/ko_KR/ | ||
H A D | index.rst | diff f7ebe6b7 Tue May 25 09:25:39 MDT 2021 Akira Yokosawa <akiyks@gmail.com> docs: Activate exCJK only in CJK chapters Activating xeCJK in English and Italian-translation documents results in sub-optimal typesetting with wide-looking apostrophes and quotation marks. The xeCJK package provides macros for enabling and disabling its effect in the middle of a document, namely \makexeCJKactive and \makexeCJKinactive. So the goal of this change is to activate xeCJK in the relevant chapters in translations. To do this: o Define custom macros in the preamble depending on the availability of the "Noto Sans CJK" font so that those macros can be used regardless of the use of xeCJK package. o Patch \sphinxtableofcontents so that xeCJK is inactivated after table of contents. o Embed those custom macros in each language's index.rst file as a ".. raw:: latex" construct. Note: A CJK chapter needs \kerneldocCJKon in front of its chapter heading, while a non-CJK chapter should have \kerneldocCJKoff below its chapter heading. This is to make sure the CJK font is available to CJK chapter's heading and ending page's footer. Tested against Sphinx versions 2.4.4 and 4.0.2. Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Tested-by: Wu XiangCheng <bobwxc@email.cn> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/lkml/2061da0a-6ab1-35f3-99c1-dbc415444f37@gmail.com Link: https://lore.kernel.org/r/83208ddc-5de9-b283-3fd6-92c635348ca0@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net> |
/linux-master/Documentation/translations/ja_JP/ | ||
H A D | index.rst | diff f7ebe6b7 Tue May 25 09:25:39 MDT 2021 Akira Yokosawa <akiyks@gmail.com> docs: Activate exCJK only in CJK chapters Activating xeCJK in English and Italian-translation documents results in sub-optimal typesetting with wide-looking apostrophes and quotation marks. The xeCJK package provides macros for enabling and disabling its effect in the middle of a document, namely \makexeCJKactive and \makexeCJKinactive. So the goal of this change is to activate xeCJK in the relevant chapters in translations. To do this: o Define custom macros in the preamble depending on the availability of the "Noto Sans CJK" font so that those macros can be used regardless of the use of xeCJK package. o Patch \sphinxtableofcontents so that xeCJK is inactivated after table of contents. o Embed those custom macros in each language's index.rst file as a ".. raw:: latex" construct. Note: A CJK chapter needs \kerneldocCJKon in front of its chapter heading, while a non-CJK chapter should have \kerneldocCJKoff below its chapter heading. This is to make sure the CJK font is available to CJK chapter's heading and ending page's footer. Tested against Sphinx versions 2.4.4 and 4.0.2. Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Tested-by: Wu XiangCheng <bobwxc@email.cn> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/lkml/2061da0a-6ab1-35f3-99c1-dbc415444f37@gmail.com Link: https://lore.kernel.org/r/83208ddc-5de9-b283-3fd6-92c635348ca0@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net> |
/linux-master/arch/m68k/lib/ | ||
H A D | checksum.c | diff 2061acaa Tue Nov 14 22:17:19 MST 2006 Al Viro <viro@zeniv.linux.org.uk> [NET]: M68K checksum annotations and cleanups. * sanitize prototypes, annotate Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/sound/pci/echoaudio/ | ||
H A D | echoaudio_dsp.c | diff c914f55f Mon Apr 30 12:39:22 MDT 2012 Mark Hills <mark@pogo.org.uk> ALSA: echoaudio: Remove incorrect part of assertion This assertion seems to imply that chip->dsp_code_to_load is a pointer. It's actually an integer handle on the actual firmware, and 0 has no special meaning. The assertion prevents initialisation of a Darla20 card, but would also affect other models. It seems it was introduced in commit dd7b254d. ALSA sound/pci/echoaudio/echoaudio.c:2061 Echoaudio driver starting... ALSA sound/pci/echoaudio/echoaudio.c:1969 chip=ebe4e000 ALSA sound/pci/echoaudio/echoaudio.c:2007 pci=ed568000 irq=19 subdev=0010 Init hardware... ALSA sound/pci/echoaudio/darla20_dsp.c:36 init_hw() - Darla20 ------------[ cut here ]------------ WARNING: at sound/pci/echoaudio/echoaudio_dsp.c:478 init_hw+0x1d1/0x86c [snd_darla20]() Hardware name: Dell DM051 BUG? (!chip->dsp_code_to_load || !chip->comm_page) Signed-off-by: Mark Hills <mark@pogo.org.uk> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> |
/linux-master/Documentation/translations/it_IT/ | ||
H A D | index.rst | diff f7ebe6b7 Tue May 25 09:25:39 MDT 2021 Akira Yokosawa <akiyks@gmail.com> docs: Activate exCJK only in CJK chapters Activating xeCJK in English and Italian-translation documents results in sub-optimal typesetting with wide-looking apostrophes and quotation marks. The xeCJK package provides macros for enabling and disabling its effect in the middle of a document, namely \makexeCJKactive and \makexeCJKinactive. So the goal of this change is to activate xeCJK in the relevant chapters in translations. To do this: o Define custom macros in the preamble depending on the availability of the "Noto Sans CJK" font so that those macros can be used regardless of the use of xeCJK package. o Patch \sphinxtableofcontents so that xeCJK is inactivated after table of contents. o Embed those custom macros in each language's index.rst file as a ".. raw:: latex" construct. Note: A CJK chapter needs \kerneldocCJKon in front of its chapter heading, while a non-CJK chapter should have \kerneldocCJKoff below its chapter heading. This is to make sure the CJK font is available to CJK chapter's heading and ending page's footer. Tested against Sphinx versions 2.4.4 and 4.0.2. Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Tested-by: Wu XiangCheng <bobwxc@email.cn> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/lkml/2061da0a-6ab1-35f3-99c1-dbc415444f37@gmail.com Link: https://lore.kernel.org/r/83208ddc-5de9-b283-3fd6-92c635348ca0@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net> |
/linux-master/fs/ufs/ | ||
H A D | util.c | diff 2061df0f Sun Jun 25 06:47:18 MDT 2006 Evgeniy Dushistov <dushistov@mail.ru> [PATCH] ufs: ufs_trunc_indirect: infinite cycle Currently, ufs write support have two sets of problems: work with files and work with directories. This series of patches should solve the first problem. This patch is similar to http://lkml.org/lkml/2006/1/17/61 this patch complements it. The situation the same: in ufs_trunc_(not direct), we read block, check if count of links to it is equal to one, if so we finish cycle, if not continue. Because of "count of links" always >=2 this operation cause infinite cycle and hang up the kernel. Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> |
H A D | util.h | diff 2061df0f Sun Jun 25 06:47:18 MDT 2006 Evgeniy Dushistov <dushistov@mail.ru> [PATCH] ufs: ufs_trunc_indirect: infinite cycle Currently, ufs write support have two sets of problems: work with files and work with directories. This series of patches should solve the first problem. This patch is similar to http://lkml.org/lkml/2006/1/17/61 this patch complements it. The situation the same: in ufs_trunc_(not direct), we read block, check if count of links to it is equal to one, if so we finish cycle, if not continue. Because of "count of links" always >=2 this operation cause infinite cycle and hang up the kernel. Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> |
/linux-master/drivers/net/wireless/intel/iwlegacy/ | ||
H A D | 3945-mac.c | diff dd13d6dc Wed Aug 26 03:33:34 MDT 2020 Lee Jones <lee.jones@linaro.org> iwlegacy: 3945-mac: Remove all non-conformant kernel-doc headers Fixes the following W=1 kernel build warning(s): drivers/net/wireless/intel/iwlegacy/3945-mac.c:821: warning: Function parameter or member 'il' not described in 'il3945_setup_handlers' drivers/net/wireless/intel/iwlegacy/3945-mac.c:915: warning: Function parameter or member 'il' not described in 'il3945_dma_addr2rbd_ptr' drivers/net/wireless/intel/iwlegacy/3945-mac.c:915: warning: Function parameter or member 'dma_addr' not described in 'il3945_dma_addr2rbd_ptr' drivers/net/wireless/intel/iwlegacy/3945-mac.c:932: warning: Function parameter or member 'il' not described in 'il3945_rx_queue_restock' drivers/net/wireless/intel/iwlegacy/3945-mac.c:979: warning: Function parameter or member 'il' not described in 'il3945_rx_allocate' drivers/net/wireless/intel/iwlegacy/3945-mac.c:979: warning: Function parameter or member 'priority' not described in 'il3945_rx_allocate' drivers/net/wireless/intel/iwlegacy/3945-mac.c:1179: warning: Function parameter or member 'il' not described in 'il3945_rx_handle' drivers/net/wireless/intel/iwlegacy/3945-mac.c:1663: warning: Function parameter or member 'il' not described in 'il3945_verify_inst_full' drivers/net/wireless/intel/iwlegacy/3945-mac.c:1663: warning: Function parameter or member 'image' not described in 'il3945_verify_inst_full' drivers/net/wireless/intel/iwlegacy/3945-mac.c:1663: warning: Function parameter or member 'len' not described in 'il3945_verify_inst_full' drivers/net/wireless/intel/iwlegacy/3945-mac.c:1703: warning: Function parameter or member 'il' not described in 'il3945_verify_inst_sparse' drivers/net/wireless/intel/iwlegacy/3945-mac.c:1703: warning: Function parameter or member 'image' not described in 'il3945_verify_inst_sparse' drivers/net/wireless/intel/iwlegacy/3945-mac.c:1703: warning: Function parameter or member 'len' not described in 'il3945_verify_inst_sparse' drivers/net/wireless/intel/iwlegacy/3945-mac.c:1739: warning: Function parameter or member 'il' not described in 'il3945_verify_ucode' drivers/net/wireless/intel/iwlegacy/3945-mac.c:1821: warning: Function parameter or member 'il' not described in 'il3945_read_ucode' drivers/net/wireless/intel/iwlegacy/3945-mac.c:2061: warning: Function parameter or member 'il' not described in 'il3945_set_ucode_ptrs' drivers/net/wireless/intel/iwlegacy/3945-mac.c:2093: warning: Function parameter or member 'il' not described in 'il3945_init_alive_start' drivers/net/wireless/intel/iwlegacy/3945-mac.c:2135: warning: Function parameter or member 'il' not described in 'il3945_alive_start' Cc: Stanislaw Gruszka <stf_xl@wp.pl> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Linux Wireless <ilw@linux.intel.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200826093401.1458456-4-lee.jones@linaro.org |
/linux-master/tools/perf/Documentation/ | ||
H A D | perf-trace.txt | diff f078c385 Sat Feb 21 12:36:52 MST 2015 Arnaldo Carvalho de Melo <acme@redhat.com> perf trace: Introduce --filter-pids When tracing in X we get event loops due to the tracing activity, i.e. updates to a gnome-terminal that generate syscalls for X.org, etc. To get a more useful view of what is happening, syscall wise, system wide, we need to filter those, like in: # ps ax|egrep '981|2296|1519' | grep -v egrep 981 tty1 Ss+ 5:40 /usr/bin/Xorg :0 -background none ... 1519 ? Sl 2:22 /usr/bin/gnome-shell 2296 ? Sl 4:16 /usr/libexec/gnome-terminal-server # # trace -e write --filter-pids 981,2296,1519 0.385 ( 0.021 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 136) = 136 0.922 ( 0.014 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 140) = 140 5006.525 ( 0.029 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 136) = 136 5007.235 ( 0.023 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 140) = 140 5177.646 ( 0.018 ms): rtkit-daemon/782 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7f7eea70be88, count: 8) = 8 8314.497 ( 0.004 ms): gsd-locate-poi/2084 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7fffe96af7b0, count: 8) = 8 8314.518 ( 0.002 ms): gsd-locate-poi/2084 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7fffe96af0e0, count: 8) = 8 ^C# When this option is used the tracer pid is also filtered. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-f5qmiyy7c0uxdm21ncatpeek@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> diff f078c385 Sat Feb 21 12:36:52 MST 2015 Arnaldo Carvalho de Melo <acme@redhat.com> perf trace: Introduce --filter-pids When tracing in X we get event loops due to the tracing activity, i.e. updates to a gnome-terminal that generate syscalls for X.org, etc. To get a more useful view of what is happening, syscall wise, system wide, we need to filter those, like in: # ps ax|egrep '981|2296|1519' | grep -v egrep 981 tty1 Ss+ 5:40 /usr/bin/Xorg :0 -background none ... 1519 ? Sl 2:22 /usr/bin/gnome-shell 2296 ? Sl 4:16 /usr/libexec/gnome-terminal-server # # trace -e write --filter-pids 981,2296,1519 0.385 ( 0.021 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 136) = 136 0.922 ( 0.014 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 140) = 140 5006.525 ( 0.029 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 136) = 136 5007.235 ( 0.023 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 140) = 140 5177.646 ( 0.018 ms): rtkit-daemon/782 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7f7eea70be88, count: 8) = 8 8314.497 ( 0.004 ms): gsd-locate-poi/2084 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7fffe96af7b0, count: 8) = 8 8314.518 ( 0.002 ms): gsd-locate-poi/2084 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7fffe96af0e0, count: 8) = 8 ^C# When this option is used the tracer pid is also filtered. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-f5qmiyy7c0uxdm21ncatpeek@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> diff f078c385 Sat Feb 21 12:36:52 MST 2015 Arnaldo Carvalho de Melo <acme@redhat.com> perf trace: Introduce --filter-pids When tracing in X we get event loops due to the tracing activity, i.e. updates to a gnome-terminal that generate syscalls for X.org, etc. To get a more useful view of what is happening, syscall wise, system wide, we need to filter those, like in: # ps ax|egrep '981|2296|1519' | grep -v egrep 981 tty1 Ss+ 5:40 /usr/bin/Xorg :0 -background none ... 1519 ? Sl 2:22 /usr/bin/gnome-shell 2296 ? Sl 4:16 /usr/libexec/gnome-terminal-server # # trace -e write --filter-pids 981,2296,1519 0.385 ( 0.021 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 136) = 136 0.922 ( 0.014 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 140) = 140 5006.525 ( 0.029 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 136) = 136 5007.235 ( 0.023 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 140) = 140 5177.646 ( 0.018 ms): rtkit-daemon/782 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7f7eea70be88, count: 8) = 8 8314.497 ( 0.004 ms): gsd-locate-poi/2084 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7fffe96af7b0, count: 8) = 8 8314.518 ( 0.002 ms): gsd-locate-poi/2084 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7fffe96af0e0, count: 8) = 8 ^C# When this option is used the tracer pid is also filtered. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-f5qmiyy7c0uxdm21ncatpeek@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> diff f078c385 Sat Feb 21 12:36:52 MST 2015 Arnaldo Carvalho de Melo <acme@redhat.com> perf trace: Introduce --filter-pids When tracing in X we get event loops due to the tracing activity, i.e. updates to a gnome-terminal that generate syscalls for X.org, etc. To get a more useful view of what is happening, syscall wise, system wide, we need to filter those, like in: # ps ax|egrep '981|2296|1519' | grep -v egrep 981 tty1 Ss+ 5:40 /usr/bin/Xorg :0 -background none ... 1519 ? Sl 2:22 /usr/bin/gnome-shell 2296 ? Sl 4:16 /usr/libexec/gnome-terminal-server # # trace -e write --filter-pids 981,2296,1519 0.385 ( 0.021 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 136) = 136 0.922 ( 0.014 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 140) = 140 5006.525 ( 0.029 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 136) = 136 5007.235 ( 0.023 ms): goa-daemon/2061 write(fd: 1</dev/null>, buf: 0x7fbeb017b000, count: 140) = 140 5177.646 ( 0.018 ms): rtkit-daemon/782 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7f7eea70be88, count: 8) = 8 8314.497 ( 0.004 ms): gsd-locate-poi/2084 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7fffe96af7b0, count: 8) = 8 8314.518 ( 0.002 ms): gsd-locate-poi/2084 write(fd: 5<anon_inode:[eventfd]>, buf: 0x7fffe96af0e0, count: 8) = 8 ^C# When this option is used the tracer pid is also filtered. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: David Ahern <dsahern@gmail.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/n/tip-f5qmiyy7c0uxdm21ncatpeek@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> |
/linux-master/Documentation/devicetree/bindings/arm/omap/ | ||
H A D | omap.txt | diff 2061d74d Tue Mar 22 21:34:13 MDT 2016 Lokesh Vutla <lokeshvutla@ti.com> ARM: dts: am335x: Add initial support for ICEv2 board TI's Industrial Communication Engine EVM is a low cost hardware mainly developed for industrial communication type applications using serial or Ethernet based interfaces. This platform features TI's AM3359 with 800MHz single core Cortex-A8 processor, 256MB DDR3, 64MB SPI flash, 8MB NOR Flash, mmc, usb, can, dual Ethernet ports. For more information, look at HW user guide[1], Data manual[2]. Just add basic support for the moment. [1] http://processors.wiki.ti.com/index.php/AM335x_Industrial_Communication_Engine_EVM_Rev2_1_HW_User_Guide [2] http://www.ti.com/lit/ds/symlink/am3359.pdf Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> |
/linux-master/net/core/ | ||
H A D | lwt_bpf.c | diff e7c87bd6 Tue Jan 15 18:19:22 MST 2019 Willem de Bruijn <willemb@google.com> bpf: in __bpf_redirect_no_mac pull mac only if present Syzkaller was able to construct a packet of negative length by redirecting from bpf_prog_test_run_skb with BPF_PROG_TYPE_LWT_XMIT: BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:345 [inline] BUG: KASAN: slab-out-of-bounds in skb_copy_from_linear_data include/linux/skbuff.h:3421 [inline] BUG: KASAN: slab-out-of-bounds in __pskb_copy_fclone+0x2dd/0xeb0 net/core/skbuff.c:1395 Read of size 4294967282 at addr ffff8801d798009c by task syz-executor2/12942 kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267 memcpy+0x23/0x50 mm/kasan/kasan.c:302 memcpy include/linux/string.h:345 [inline] skb_copy_from_linear_data include/linux/skbuff.h:3421 [inline] __pskb_copy_fclone+0x2dd/0xeb0 net/core/skbuff.c:1395 __pskb_copy include/linux/skbuff.h:1053 [inline] pskb_copy include/linux/skbuff.h:2904 [inline] skb_realloc_headroom+0xe7/0x120 net/core/skbuff.c:1539 ipip6_tunnel_xmit net/ipv6/sit.c:965 [inline] sit_tunnel_xmit+0xe1b/0x30d0 net/ipv6/sit.c:1029 __netdev_start_xmit include/linux/netdevice.h:4325 [inline] netdev_start_xmit include/linux/netdevice.h:4334 [inline] xmit_one net/core/dev.c:3219 [inline] dev_hard_start_xmit+0x295/0xc90 net/core/dev.c:3235 __dev_queue_xmit+0x2f0d/0x3950 net/core/dev.c:3805 dev_queue_xmit+0x17/0x20 net/core/dev.c:3838 __bpf_tx_skb net/core/filter.c:2016 [inline] __bpf_redirect_common net/core/filter.c:2054 [inline] __bpf_redirect+0x5cf/0xb20 net/core/filter.c:2061 ____bpf_clone_redirect net/core/filter.c:2094 [inline] bpf_clone_redirect+0x2f6/0x490 net/core/filter.c:2066 bpf_prog_41f2bcae09cd4ac3+0xb25/0x1000 The generated test constructs a packet with mac header, network header, skb->data pointing to network header and skb->len 0. Redirecting to a sit0 through __bpf_redirect_no_mac pulls the mac length, even though skb->data already is at skb->network_header. bpf_prog_test_run_skb has already pulled it as LWT_XMIT !is_l2. Update the offset calculation to pull only if skb->data differs from skb->network_header, which is not true in this case. The test itself can be run only from commit 1cf1cae963c2 ("bpf: introduce BPF_PROG_TEST_RUN command"), but the same type of packets with skb at network header could already be built from lwt xmit hooks, so this fix is more relevant to that commit. Also set the mac header on redirect from LWT_XMIT, as even after this change to __bpf_redirect_no_mac that field is expected to be set, but is not yet in ip_finish_output2. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Acked-by: Martin KaFai Lau <kafai@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> |
/linux-master/drivers/gpu/drm/ | ||
H A D | drm_edid_load.c | diff 80afdfa6 Mon Nov 14 04:17:09 MST 2022 Jani Nikula <jani.nikula@intel.com> drm/edid/firmware: stop using a throwaway platform device We've used a temporary platform device for firmware EDID loading since it was introduced in commit da0df92b5731 ("drm: allow loading an EDID as firmware to override broken monitor"), but there's no explanation why. Using a temporary device does not play well with CONFIG_FW_CACHE=y, which caches firmware images (e.g. on suspend) so that drivers can request firmware when the system is not ready for it, and return the images from the cache (e.g. during resume). This works automatically for regular devices, but obviously not for a temporarily created device. Stop using the throwaway platform device, and use the drm device instead. Note that this may still be problematic for cases where the display was plugged in during suspend, and the firmware wasn't loaded and therefore not cached before suspend. References: https://lore.kernel.org/r/20220727074152.43059-1-matthieu.charette@gmail.com Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2061 Reported-by: Matthieu CHARETTE <matthieu.charette@gmail.com> Tested-by: Matthieu CHARETTE <matthieu.charette@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20221114111709.434979-1-jani.nikula@intel.com |
/linux-master/Documentation/translations/zh_CN/ | ||
H A D | index.rst | diff f7ebe6b7 Tue May 25 09:25:39 MDT 2021 Akira Yokosawa <akiyks@gmail.com> docs: Activate exCJK only in CJK chapters Activating xeCJK in English and Italian-translation documents results in sub-optimal typesetting with wide-looking apostrophes and quotation marks. The xeCJK package provides macros for enabling and disabling its effect in the middle of a document, namely \makexeCJKactive and \makexeCJKinactive. So the goal of this change is to activate xeCJK in the relevant chapters in translations. To do this: o Define custom macros in the preamble depending on the availability of the "Noto Sans CJK" font so that those macros can be used regardless of the use of xeCJK package. o Patch \sphinxtableofcontents so that xeCJK is inactivated after table of contents. o Embed those custom macros in each language's index.rst file as a ".. raw:: latex" construct. Note: A CJK chapter needs \kerneldocCJKon in front of its chapter heading, while a non-CJK chapter should have \kerneldocCJKoff below its chapter heading. This is to make sure the CJK font is available to CJK chapter's heading and ending page's footer. Tested against Sphinx versions 2.4.4 and 4.0.2. Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Tested-by: Wu XiangCheng <bobwxc@email.cn> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/lkml/2061da0a-6ab1-35f3-99c1-dbc415444f37@gmail.com Link: https://lore.kernel.org/r/83208ddc-5de9-b283-3fd6-92c635348ca0@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net> |
/linux-master/drivers/net/ethernet/chelsio/cxgb4/ | ||
H A D | cxgb4_ethtool.c | diff 2061ec3f Fri May 19 06:20:15 MDT 2017 Ganesh Goudar <ganeshgr@chelsio.com> cxgb4 : retrieve port information from firmware issue get port information command to firmware to retrieve port information and update if it is different from what was last recorded and also add indication for supported link modes for firmware port types FW_PORT_TYPE_SFP28, FW_PORT_TYPE_KR_SFP28, FW_PORT_TYPE_CR4_QSFP. Based on the original work by Casey Leedom <leedom@chelsio.com> Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | t4fw_api.h | diff 2061ec3f Fri May 19 06:20:15 MDT 2017 Ganesh Goudar <ganeshgr@chelsio.com> cxgb4 : retrieve port information from firmware issue get port information command to firmware to retrieve port information and update if it is different from what was last recorded and also add indication for supported link modes for firmware port types FW_PORT_TYPE_SFP28, FW_PORT_TYPE_KR_SFP28, FW_PORT_TYPE_CR4_QSFP. Based on the original work by Casey Leedom <leedom@chelsio.com> Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | t4_hw.c | diff 2061ec3f Fri May 19 06:20:15 MDT 2017 Ganesh Goudar <ganeshgr@chelsio.com> cxgb4 : retrieve port information from firmware issue get port information command to firmware to retrieve port information and update if it is different from what was last recorded and also add indication for supported link modes for firmware port types FW_PORT_TYPE_SFP28, FW_PORT_TYPE_KR_SFP28, FW_PORT_TYPE_CR4_QSFP. Based on the original work by Casey Leedom <leedom@chelsio.com> Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | cxgb4.h | diff 2061ec3f Fri May 19 06:20:15 MDT 2017 Ganesh Goudar <ganeshgr@chelsio.com> cxgb4 : retrieve port information from firmware issue get port information command to firmware to retrieve port information and update if it is different from what was last recorded and also add indication for supported link modes for firmware port types FW_PORT_TYPE_SFP28, FW_PORT_TYPE_KR_SFP28, FW_PORT_TYPE_CR4_QSFP. Based on the original work by Casey Leedom <leedom@chelsio.com> Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/drivers/media/usb/em28xx/ | ||
H A D | em28xx-dvb.c | diff f410b409 Mon Dec 11 05:05:02 MST 2017 Arnd Bergmann <arnd@arndb.de> media: em28xx: split up em28xx_dvb_init to reduce stack size With CONFIG_KASAN, the init function uses a large amount of kernel stack: drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init.part.4': drivers/media/usb/em28xx/em28xx-dvb.c:2061:1: error: the frame size of 3232 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Using gcc-7 with -fsanitize-address-use-after-scope makes this even worse: drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': drivers/media/usb/em28xx/em28xx-dvb.c:2069:1: error: the frame size of 4280 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] By splitting out each part of the switch/case statement that has its own local variables into a separate function, no single one of them uses more than 500 bytes, and with a noinline_for_stack annotation we can ensure that they are not merged back together. [mchehab@s-opensource.com: fix conflict with changeset be7fd3c3a8c5 ("media: em28xx: Hauppauge DualHD second tuner functionality")] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> |
/linux-master/drivers/scsi/bnx2i/ | ||
H A D | bnx2i_iscsi.c | diff 14936b1e Sat Feb 06 21:46:02 MST 2021 Mike Christie <michael.christie@oracle.com> scsi: libiscsi: Fix iscsi_task use after free() The following bug was reported and debugged by wubo40@huawei.com: When testing kernel 4.18 version, NULL pointer dereference problem occurs in iscsi_eh_cmd_timed_out() function. I think this bug in the upstream is still exists. The analysis reasons are as follows: 1) For some reason, I/O command did not complete within the timeout period. The block layer timer works, call scsi_times_out() to handle I/O timeout logic. At the same time the command just completes. 2) scsi_times_out() call iscsi_eh_cmd_timed_out() to process timeout logic. Although there is an NULL judgment for the task, the task has not been released yet now. 3) iscsi_complete_task() calls __iscsi_put_task(). The task reference count reaches zero, the conditions for free task is met, then iscsi_free_task() frees the task, and sets sc->SCp.ptr = NULL. After iscsi_eh_cmd_timed_out() passes the task judgment check, there can still be NULL dereference scenarios. CPU0 CPU3 |- scsi_times_out() |- iscsi_complete_task() | | |- iscsi_eh_cmd_timed_out() |- __iscsi_put_task() | | |- task=sc->SCp.ptr, task is not NUL, check passed |- iscsi_free_task(task) | | | |-> sc->SCp.ptr = NULL | | |- task is NULL now, NULL pointer dereference | | | \|/ \|/ Calltrace: [380751.840862] BUG: unable to handle kernel NULL pointer dereference at 0000000000000138 [380751.843709] PGD 0 P4D 0 [380751.844770] Oops: 0000 [#1] SMP PTI [380751.846283] CPU: 0 PID: 403 Comm: kworker/0:1H Kdump: loaded Tainted: G [380751.851467] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [380751.856521] Workqueue: kblockd blk_mq_timeout_work [380751.858527] RIP: 0010:iscsi_eh_cmd_timed_out+0x15e/0x2e0 [libiscsi] [380751.861129] Code: 83 ea 01 48 8d 74 d0 08 48 8b 10 48 8b 4a 50 48 85 c9 74 2c 48 39 d5 74 [380751.868811] RSP: 0018:ffffc1e280a5fd58 EFLAGS: 00010246 [380751.870978] RAX: ffff9fd1e84e15e0 RBX: ffff9fd1e84e6dd0 RCX: 0000000116acc580 [380751.873791] RDX: ffff9fd1f97a9400 RSI: ffff9fd1e84e1800 RDI: ffff9fd1e4d6d420 [380751.876059] RBP: ffff9fd1e4d49000 R08: 0000000116acc580 R09: 0000000116acc580 [380751.878284] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9fd1e6e931e8 [380751.880500] R13: ffff9fd1e84e6ee0 R14: 0000000000000010 R15: 0000000000000003 [380751.882687] FS: 0000000000000000(0000) GS:ffff9fd1fac00000(0000) knlGS:0000000000000000 [380751.885236] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [380751.887059] CR2: 0000000000000138 CR3: 000000011860a001 CR4: 00000000003606f0 [380751.889308] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [380751.891523] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [380751.893738] Call Trace: [380751.894639] scsi_times_out+0x60/0x1c0 [380751.895861] blk_mq_check_expired+0x144/0x200 [380751.897302] ? __switch_to_asm+0x35/0x70 [380751.898551] blk_mq_queue_tag_busy_iter+0x195/0x2e0 [380751.900091] ? __blk_mq_requeue_request+0x100/0x100 [380751.901611] ? __switch_to_asm+0x41/0x70 [380751.902853] ? __blk_mq_requeue_request+0x100/0x100 [380751.904398] blk_mq_timeout_work+0x54/0x130 [380751.905740] process_one_work+0x195/0x390 [380751.907228] worker_thread+0x30/0x390 [380751.908713] ? process_one_work+0x390/0x390 [380751.910350] kthread+0x10d/0x130 [380751.911470] ? kthread_flush_work_fn+0x10/0x10 [380751.913007] ret_from_fork+0x35/0x40 crash> dis -l iscsi_eh_cmd_timed_out+0x15e xxxxx/drivers/scsi/libiscsi.c: 2062 1970 enum blk_eh_timer_return iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc) { ... 1984 spin_lock_bh(&session->frwd_lock); 1985 task = (struct iscsi_task *)sc->SCp.ptr; 1986 if (!task) { 1987 /* 1988 * Raced with completion. Blk layer has taken ownership 1989 * so let timeout code complete it now. 1990 */ 1991 rc = BLK_EH_DONE; 1992 goto done; 1993 } ... 2052 for (i = 0; i < conn->session->cmds_max; i++) { 2053 running_task = conn->session->cmds[i]; 2054 if (!running_task->sc || running_task == task || 2055 running_task->state != ISCSI_TASK_RUNNING) 2056 continue; 2057 2058 /* 2059 * Only check if cmds started before this one have made 2060 * progress, or this could never fail 2061 */ 2062 if (time_after(running_task->sc->jiffies_at_alloc, 2063 task->sc->jiffies_at_alloc)) <--- 2064 continue; 2065 ... } carsh> struct scsi_cmnd ffff9fd1e6e931e8 struct scsi_cmnd { ... SCp = { ptr = 0x0, <--- iscsi_task this_residual = 0, ... }, } To prevent this, we take a ref to the cmd under the back (completion) lock so if the completion side were to call iscsi_complete_task() on the task while the timer/eh paths are not holding the back_lock it will not be freed from under us. Note that this requires the previous patch, "scsi: libiscsi: Drop taskqueuelock" because bnx2i sleeps in its cleanup_task callout if the cmd is aborted. If the EH/timer and completion path are racing we don't know which path will do the last put. The previous patch moved the operations we needed to do under the forward lock to cleanup_queued_task. Once that has run we can drop the forward lock for the cmd and bnx2i no longer has to worry about if the EH, timer or completion path did the ast put and if the forward lock is held or not since it won't be. Link: https://lore.kernel.org/r/20210207044608.27585-4-michael.christie@oracle.com Reported-by: Wu Bo <wubo40@huawei.com> Reviewed-by: Lee Duncan <lduncan@suse.com> Signed-off-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> |
/linux-master/drivers/gpu/drm/nouveau/ | ||
H A D | nouveau_bios.c | diff 78ad449d Fri Mar 19 02:40:40 MDT 2021 Jiapeng Chong <jiapeng.chong@linux.alibaba.com> drm/nouveau: Remove unused variable ret Fix the following coccicheck warnings: ./drivers/gpu/drm/nouveau/nouveau_bios.c:2048:5-8: Unneeded variable: "ret". Return "0" on line 2061. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/10 |
/linux-master/Documentation/ | ||
H A D | conf.py | diff f7ebe6b7 Tue May 25 09:25:39 MDT 2021 Akira Yokosawa <akiyks@gmail.com> docs: Activate exCJK only in CJK chapters Activating xeCJK in English and Italian-translation documents results in sub-optimal typesetting with wide-looking apostrophes and quotation marks. The xeCJK package provides macros for enabling and disabling its effect in the middle of a document, namely \makexeCJKactive and \makexeCJKinactive. So the goal of this change is to activate xeCJK in the relevant chapters in translations. To do this: o Define custom macros in the preamble depending on the availability of the "Noto Sans CJK" font so that those macros can be used regardless of the use of xeCJK package. o Patch \sphinxtableofcontents so that xeCJK is inactivated after table of contents. o Embed those custom macros in each language's index.rst file as a ".. raw:: latex" construct. Note: A CJK chapter needs \kerneldocCJKon in front of its chapter heading, while a non-CJK chapter should have \kerneldocCJKoff below its chapter heading. This is to make sure the CJK font is available to CJK chapter's heading and ending page's footer. Tested against Sphinx versions 2.4.4 and 4.0.2. Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Tested-by: Wu XiangCheng <bobwxc@email.cn> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/lkml/2061da0a-6ab1-35f3-99c1-dbc415444f37@gmail.com Link: https://lore.kernel.org/r/83208ddc-5de9-b283-3fd6-92c635348ca0@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net> |
/linux-master/net/openvswitch/ | ||
H A D | conntrack.c | diff 2061ecfdf Mon Jun 06 16:11:40 MDT 2022 Ilya Maximets <i.maximets@ovn.org> net: openvswitch: fix misuse of the cached connection on tuple changes If packet headers changed, the cached nfct is no longer relevant for the packet and attempt to re-use it leads to the incorrect packet classification. This issue is causing broken connectivity in OpenStack deployments with OVS/OVN due to hairpin traffic being unexpectedly dropped. The setup has datapath flows with several conntrack actions and tuple changes between them: actions:ct(commit,zone=8,mark=0/0x1,nat(src)), set(eth(src=00:00:00:00:00:01,dst=00:00:00:00:00:06)), set(ipv4(src=172.18.2.10,dst=192.168.100.6,ttl=62)), ct(zone=8),recirc(0x4) After the first ct() action the packet headers are almost fully re-written. The next ct() tries to re-use the existing nfct entry and marks the packet as invalid, so it gets dropped later in the pipeline. Clearing the cached conntrack entry whenever packet tuple is changed to avoid the issue. The flow key should not be cleared though, because we should still be able to match on the ct_state if the recirculation happens after the tuple change but before the next ct() action. Cc: stable@vger.kernel.org Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action") Reported-by: Frode Nordahl <frode.nordahl@canonical.com> Link: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051829.html Link: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/1967856 Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Link: https://lore.kernel.org/r/20220606221140.488984-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
H A D | actions.c | diff 2061ecfdf Mon Jun 06 16:11:40 MDT 2022 Ilya Maximets <i.maximets@ovn.org> net: openvswitch: fix misuse of the cached connection on tuple changes If packet headers changed, the cached nfct is no longer relevant for the packet and attempt to re-use it leads to the incorrect packet classification. This issue is causing broken connectivity in OpenStack deployments with OVS/OVN due to hairpin traffic being unexpectedly dropped. The setup has datapath flows with several conntrack actions and tuple changes between them: actions:ct(commit,zone=8,mark=0/0x1,nat(src)), set(eth(src=00:00:00:00:00:01,dst=00:00:00:00:00:06)), set(ipv4(src=172.18.2.10,dst=192.168.100.6,ttl=62)), ct(zone=8),recirc(0x4) After the first ct() action the packet headers are almost fully re-written. The next ct() tries to re-use the existing nfct entry and marks the packet as invalid, so it gets dropped later in the pipeline. Clearing the cached conntrack entry whenever packet tuple is changed to avoid the issue. The flow key should not be cleared though, because we should still be able to match on the ct_state if the recirculation happens after the tuple change but before the next ct() action. Cc: stable@vger.kernel.org Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action") Reported-by: Frode Nordahl <frode.nordahl@canonical.com> Link: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051829.html Link: https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/1967856 Signed-off-by: Ilya Maximets <i.maximets@ovn.org> Link: https://lore.kernel.org/r/20220606221140.488984-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
/linux-master/net/bluetooth/ | ||
H A D | l2cap_core.c | diff bcd70260 Fri Nov 18 13:01:47 MST 2022 Sungwoo Kim <iam@sung-woo.kim> Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@... Signed-off-by: Sungwoo Kim <iam@sung-woo.kim> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> diff bcd70260 Fri Nov 18 13:01:47 MST 2022 Sungwoo Kim <iam@sung-woo.kim> Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@... Signed-off-by: Sungwoo Kim <iam@sung-woo.kim> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> diff bcd70260 Fri Nov 18 13:01:47 MST 2022 Sungwoo Kim <iam@sung-woo.kim> Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@... Signed-off-by: Sungwoo Kim <iam@sung-woo.kim> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> diff bcd70260 Fri Nov 18 13:01:47 MST 2022 Sungwoo Kim <iam@sung-woo.kim> Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@... Signed-off-by: Sungwoo Kim <iam@sung-woo.kim> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> |
Completed in 805 milliseconds