Semantic Matching Tool

• Thread Index

• Fwd: [PATCH] Makefile: remove SMATCH_DATA smatch_data/kernel.balanced_funcs item
  • From: Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx>
• Re: sparse on scripts/kconfig/*.c
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: sparse on scripts/kconfig/*.c
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• Re: sparse on scripts/kconfig/*.c
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• C Safety and Security Study Group
  • From: Laurence Urhegyi <laurence.urhegyi@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/3] check_kernel_printf: check that %pg gets a block_device
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• [PATCH 1/3] check_kernel_printf: check that %pg gets a block_device
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 3/3] check_kernel_printf.c: handle new definition of KERN_CONT
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 2/3] check_kernel_printf.c: %pj ended up being %pG
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• Re: smatch db errors?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch db errors?
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• smatch db errors?
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [BUG] segfault when analysing powerpc kernel code
  • From: Andrew Donnellan <andrew.donnellan@xxxxxxxxxxx>
• Re: [BUG] segfault when analysing powerpc kernel code
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [BUG] segfault when analysing powerpc kernel code
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• [BUG] segfault when analysing powerpc kernel code
  • From: Andrew Donnellan <andrew.donnellan@xxxxxxxxxxx>
• Aw: Re: Re: REGRESSION: implied: we have to make the false states match as well
  • From: conchur@xxxxxx
• Re: Re: REGRESSION: implied: we have to make the false states match as well
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Aw: Re: REGRESSION: implied: we have to make the false states match as well
  • From: conchur@xxxxxx
• Re: REGRESSION: implied: we have to make the false states match as well
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• REGRESSION: implied: we have to make the false states match as well
  • From: conchur@xxxxxx
• new false positives after the recent pull?
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: Memory leak warning - false positive
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Memory leak warning - false positive
  • From: "Amir Vadai\"" <amir@xxxxxxxx>
• Re: Memory leak warning - false positive
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Memory leak warning - false positive
  • From: "Amir Vadai\"" <amir@xxxxxxxx>
• Re: Memory leak warning - false positive
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Memory leak warning - false positive
  • From: "Amir Vadai\"" <amir@xxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Oleg Drokin <GREEN@xxxxxxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Oleg Drokin <GREEN@xxxxxxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Oleg Drokin <GREEN@xxxxxxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Oleg Drokin <GREEN@xxxxxxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Oleg Drokin <GREEN@xxxxxxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Better handling of always true conditions.
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Better handling of always true conditions.
  • From: Oleg Drokin <GREEN@xxxxxxxxxxxxxx>
• [PATCH] slist: Properly handle one-way merges
  • From: green@xxxxxxxxxxxxxx
• Re: [PATCH] slist: Properly handle one-way merges
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [PATCH 7/9] check_kernel_printf.c: support future %pgX
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH 7/9] check_kernel_printf.c: support future %pgX
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: [PATCH 7/9] check_kernel_printf.c: support future %pgX
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH 0/9] some check_kernel_printf updates
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• [PATCH 9/9] check_kernel_printf.c: check for redundant or confusing 0x prefix
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 8/9] check_kernel_printf.c: actually allow printk level via %c
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 7/9] check_kernel_printf.c: support future %pgX
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 6/9] check_kernel_printf.c: support %pC
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 5/9] check_kernel_printf.c: remove some %pIS false positives
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 4/9] check_kernel_printf.c: check for signed char versus %02x issue
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 3/9] check_kernel_printf.c: update struct printf_spec to kernel version
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 2/9] check_kernel_printf.c: reorder flag defines
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 1/9] sparse: don't warn about unknown attributes
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• [PATCH 0/9] some check_kernel_printf updates
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• smatch: Regression in unused return check
  • From: conchur@xxxxxx
• make fails
  • From: Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: Some minor tweaks
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Recent wave of additional false negative warnings?
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Recent wave of additional false negative warnings?
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [PATCH] kchecker: build already built directory
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] kchecker: build already built directory
  • From: Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx>
• Re: [PATCH] kchecker: build already built directory
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] kchecker: build already built directory
  • From: Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx>
• Re: smatch and strcmp()
  • From: Karel Zak <kzak@xxxxxxxxxx>
• Re: smatch and strcmp()
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch and strcmp()
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [linux-next:master 5659/5676] kernel/trace/trace_syscalls.c:106 syscall_nr_to_meta() error: buffer overflow 'syscalls_metadata' 374 <= 375
  • From: Fengguang Wu <fengguang.wu@xxxxxxxxx>
• Re: [linux-next:master 5659/5676] kernel/trace/trace_syscalls.c:106 syscall_nr_to_meta() error: buffer overflow 'syscalls_metadata' 374 <= 375
  • From: Fengguang Wu <fengguang.wu@xxxxxxxxx>
• Re: [linux-next:master 5659/5676] kernel/trace/trace_syscalls.c:106 syscall_nr_to_meta() error: buffer overflow 'syscalls_metadata' 374 <= 375
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] testkernel.sh to retain make exit code
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: [PATCH] testkernel.sh to retain make exit code
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] testkernel.sh to retain make exit code
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• [PATCH] testkernel.sh to retain make exit code
  • From: green@xxxxxxxxxxxxxx
• Re: Some minor tweaks
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Some minor tweaks
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Some minor tweaks
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• Re: Some minor tweaks
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Some minor tweaks
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• Re: Some minor tweaks
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Some minor tweaks
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: Some minor tweaks
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: Some minor tweaks
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Some minor tweaks
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• Re: Some minor tweaks
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Some minor tweaks
  • From: Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx>
• Re: smatch usage?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch usage?
  • From: Oleg Drokin <green@xxxxxxxxxxxxxx>
• Re: smatch usage?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• [PATCH] db: Avoid dereferencing null pointer
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• bug: got a segfault
  • From: Wolfram Sang <wsa@xxxxxxxxxxxxx>
• Re: %p extension checking
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [RFC][PATCH] Documentation fixes
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• [RFC][PATCH] Documentation fixes
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: %p extension checking
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• Re: %p extension checking
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: %p extension checking
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• Re: %p extension checking
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: %p extension checking
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: %p extension checking
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: %p extension checking
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• Re: %p extension checking
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• %p extension checking
  • From: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
• smatch v1.60 released
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: "Josef 'Jeff' Sipek" <jeffpc@xxxxxxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: "Josef 'Jeff' Sipek" <jeffpc@xxxxxxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: "Josef 'Jeff' Sipek" <jeffpc@xxxxxxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: "Josef 'Jeff' Sipek" <jeffpc@xxxxxxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: "Josef 'Jeff' Sipek" <jeffpc@xxxxxxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch on illumos & false positive
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• smatch on illumos & false positive
  • From: "Josef 'Jeff' Sipek" <jeffpc@xxxxxxxxxxxxxx>
• Re: checking for uninitialized variables
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: can't reproduce this warning
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: can't reproduce this warning
  • From: Kees Cook <keescook@xxxxxxxxxx>
• Re: can't reproduce this warning
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: can't reproduce this warning
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch: false positives related to locking
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch: false positives related to locking
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch: false positives related to locking
  • From: Wolfram Sang <wsa@xxxxxxxxxxxxx>
• Re: smatch: false positives related to locking
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: checking for uninitialized variables
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: checking for uninitialized variables
  • From: Jörn Engel <joern@xxxxxxxxxxxxxxx>
• Re: checking for uninitialized variables
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: smatch overzealous ?
  • From: walter harms <wharms@xxxxxx>
• Re: smatch overzealous ?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch overzealous ?
  • From: Jonathan Neuschäfer <j.neuschaefer@xxxxxxx>
• Re: Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Assertion error in avl.c:87 when compiling/testing Linux kernel
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: Feature request: check for freeing an ERR_PTR
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• Re: Feature request: check for freeing an ERR_PTR
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Feature request: check for freeing an ERR_PTR
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• Re: Feature request: check for freeing an ERR_PTR
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Feature request: check for freeing an ERR_PTR
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• spin_lock/unlock false positives ?
  • From: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxxxxxxxxx>
• Re: SQL error while running smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• smatch overzealous ?
  • From: walter harms <wharms@xxxxxx>
• Re: smatch output
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch output
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: smatch output
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: smatch output
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: unreachable code warnings now are fixed
  • From: Or Gerlitz <ogerlitz@xxxxxxxxxxxx>
• unreachable code warnings now are fixed
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch question
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Hit assert when checking net/netfilter/ipset/ip_set_bitmap_port.c in the Kernel
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: Hit assert when checking net/netfilter/ipset/ip_set_bitmap_port.c in the Kernel
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Hit assert when checking net/netfilter/ipset/ip_set_bitmap_port.c in the Kernel
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: Hit assert when checking net/netfilter/ipset/ip_set_bitmap_port.c in the Kernel
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Hit assert when checking net/netfilter/ipset/ip_set_bitmap_port.c in the Kernel
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Hit assert when checking net/netfilter/ipset/ip_set_bitmap_port.c in the Kernel
  • From: Silvan Jegen <s.jegen@xxxxxxxxx>
• Re: can 'mac_addr' even be NULL?
  • From: Larry Finger <Larry.Finger@xxxxxxxxxxxx>
• Re: can 'mac_addr' even be NULL?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: can 'mac_addr' even be NULL?
  • From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
• Re: can 'mac_addr' even be NULL?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: can 'mac_addr' even be NULL?
  • From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
• Re: can 'mac_addr' even be NULL?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: can 'mac_addr' even be NULL?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Regression in Smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Regression in Smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Regression in Smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Regression in Smatch
  • From: Larry Finger <Larry.Finger@xxxxxxxxxxxx>
• Re: Regression in Smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Regression in Smatch
  • From: Larry Finger <Larry.Finger@xxxxxxxxxxxx>
• Re: Adding PCI hotplug safe checking to smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Adding PCI hotplug safe checking to smatch
  • From: Joe Lawrence <joe.lawrence@xxxxxxxxxxx>
• Re: Adding PCI hotplug safe checking to smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Adding PCI hotplug safe checking to smatch
  • From: Joe Lawrence <joe.lawrence@xxxxxxxxxxx>
• Re: Adding PCI hotplug safe checking to smatch
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: Adding PCI hotplug safe checking to smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Adding PCI hotplug safe checking to smatch
  • From: Joe Lawrence <joe.lawrence@xxxxxxxxxxx>
• Re: Adding PCI hotplug safe checking to smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch "... 'buffer' too small (X vs. Y)" error messages
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• recent changes will require a db rebuild
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch "unreachable code"
  • From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
• Re: smatch "unreachable code"
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch "unreachable code"
  • From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
• Re: smatch "unreachable code"
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• [patch] allow char to be unsigned
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Signedness of 'char'
  • From: Peter Oberparleiter <oberpar@xxxxxxxxxxxxxxxxxx>
• Re: Signedness of 'char'
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Signedness of 'char'
  • From: Peter Oberparleiter <oberpar@xxxxxxxxxxxxxxxxxx>
• Re: Smatch messages that are not understood
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Smatch messages that are not understood
  • From: Larry Finger <Larry.Finger@xxxxxxxxxxxx>
• Re: Latest smatch crashing on drivers/hwmon/acpi_power_meter.c
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: Latest smatch crashing on drivers/hwmon/acpi_power_meter.c
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Latest smatch crashing on drivers/hwmon/acpi_power_meter.c
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: A sparse warning I dont understand in drivers/hwmon/max16065.c [was: smatch warning]
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: A smatch warning I dont understand in drivers/hwmon/max16065.c
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: A smatch warning I dont understand in drivers/hwmon/max16065.c
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: A smatch warning I dont understand in drivers/hwmon/max16065.c
  • From: Jonathan Neuschäfer <j.neuschaefer@xxxxxxx>
• A smatch warning I dont understand in drivers/hwmon/max16065.c
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: smatch v1.59 released
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• smatch v1.59 released
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: build regressions 2013-04-12
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Fwd: What kinds of bugs can smatch check?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• I fixed the slow down using the database
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [nfc-next:topic/char-misc-next-mei 4/11] drivers/misc/mei/bus.c:161 mei_add_device() error: dereferencing freed memory 'client'
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [kbuild] [mmotm:master 315/315] drivers/net/team/team.c:1771 team_ethtool_get_drvinfo() error: strlcpy() '"3.9.0-rc1-mm1-00315-g391ef7f"' too small (29 vs 32)
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [kbuild] smatch handling of inline functions
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [kbuild] smatch handling of inline functions
  • From: Fengguang Wu <fengguang.wu@xxxxxxxxx>
• smatch handling of inline functions
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: net/vmw_vsock/af_vsock.c:616 __vsock_create() error: potential NULL dereference 'psk'.
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Smatch 1.58 released
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Using smatch on Chrome OS kernel, cannot process "__restrict__"
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Using smatch on Chrome OS kernel, cannot process "__restrict__"
  • From: Simon Que <sque@xxxxxxxxxx>
• Re: Making the smatch output understandable for emacs
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• new sval patches
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] Makefile: drop superfluous trailing '/'
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [RFC] Makefile: use '/usr/local' as prefix
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: false positive 'double unlock'?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: false positive 'double unlock'?
  • From: Wolfram Sang <w.sang@xxxxxxxxxxxxxx>
• [PATCH] Makefile: drop superfluous trailing '/'
  • From: Wolfram Sang <wolfram@xxxxxxxxxxxxx>
• Re: false positive 'double unlock'?
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• false positive 'double unlock'?
  • From: Wolfram Sang <w.sang@xxxxxxxxxxxxxx>
• [RFC] Makefile: use '/usr/local' as prefix
  • From: Wolfram Sang <wolfram@xxxxxxxxxxxxx>
• Smatch 1.57 released
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch list and gmane
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [userns:userns-always-map-user-v58 86/150] fs/ncpfs/inode.c:335 ncp_show_options() warn: if();
  • From: Fengguang Wu <fengguang.wu@xxxxxxxxx>
• Re: [userns:userns-always-map-user-v58 86/150] fs/ncpfs/inode.c:335 ncp_show_options() warn: if();
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] Fix bug in Makefile that causes linking to fail
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• [PATCH] Fix bug in Makefile that causes linking to fail
  • From: Omair Mohammed Abdullah <omair.m.abdullah@xxxxxxxxxxxxxxx>
• smatch and nested spin_lock_bh() calls
  • From: Bart Van Assche <bvanassche@xxxxxxx>
• Re: [patch] sparse: ignore leaf attribute
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: smatch vs. WARN_ON[_ONCE]
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH 2/2] smatch_scripts: fix spelling of "usage"
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• [PATCH 2/2] smatch_scripts: fix spelling of "usage"
  • From: Jonathan Neuschäfer <j.neuschaefer@xxxxxxx>
• [PATCH 1/2] smatch: fix several typos
  • From: Jonathan Neuschäfer <j.neuschaefer@xxxxxxx>
• Re: buffer overflow check bug
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: buffer overflow check bug
  • From: Xi Wang <xi.wang@xxxxxxxxx>
• Re: buffer overflow check bug
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: buffer overflow check bug
  • From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
• Re: buffer overflow check bug
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: buffer overflow check bug
  • From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
• Re: buffer overflow check bug
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: buffer overflow check bug
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: buffer overflow check bug
  • From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
• Re: buffer overflow check bug
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: tiny patch for userland project
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: tiny patch for userland project
  • From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
• Re: buffer overflow check bug
  • From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
• Re: tiny patch for userland project
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: tiny patch for userland project
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: buffer overflow check bug
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• buffer overflow check bug
  • From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
• Re: tiny patch for userland project
  • From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
• Re: tiny patch for userland project
  • From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
• Re: tiny patch for userland project
  • From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
• Re: tiny patch for userland project
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: tiny patch for userland project
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• tiny patch for userland project
  • From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>
• Re: Questions Regarding Smatch from Nomura
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Smatch v1.56 released
  • From: Artem Bityutskiy <artem.bityutskiy@xxxxxxxxxxxxxxx>
• Re: Quick question on extending/using smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Quick question on extending/using smatch
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Quick question on extending/using smatch
  • From: Lars Segerlund <lars.segerlund@xxxxxxxxx>
• Re: Smatch v1.56 released
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: Smatch v1.56 released
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• Re: Smatch v1.56 released
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Smatch v1.56 released
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] recognize binary constants
  • From: Christopher Li <sparse@xxxxxxxxxxx>
• Re: [PATCH] recognize binary constants
  • From: Dan Carpenter <error27@xxxxxxxxx>
• Re: [PATCH] smatch: add --data=<dir> option
  • From: Dan Carpenter <error27@xxxxxxxxx>
• [PATCH] smatch: add --data=<dir> option
  • From: Karel Zak <kzak@xxxxxxxxxx>
• Re: [PATCH] recognize binary constants
  • From: Kamal Mostafa <kamal@xxxxxxxxxxxxx>
• Re: [PATCH] recognize binary constants
  • From: Dan Carpenter <error27@xxxxxxxxx>
• smatch doesn't recognize binary constants
  • From: Kamal Mostafa <kamal@xxxxxxxxxxxxx>
• Re: [PATCH smatch] fix a memory leak in compile-i386.c
  • From: Dan Carpenter <error27@xxxxxxxxx>
• [PATCH smatch] fix a memory leak in compile-i386.c
  • From: Jonathan Neuschäfer <j.neuschaefer@xxxxxxx>
• Register Your Source Code Security Analyzer Tools with the DACS
  • From: "Thomas J. Kwasniewski" <tkwasniewski@xxxxxxxxxxxxxx>