On Apr 8, 2013, at 8:45 AM, Michael Riesch michael.rie...@omicron.at wrote:
Signed-off-by: Michael Riesch michael.rie...@omicron.at
Cc: David S. Miller da...@davemloft.net
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Benc jb...@redhat.com
Cc: Theodore Ts'o ty...@mit.edu
Cc:
On Aug 18, 2012, at 3:35 PM, Nicholas A. Bellinger wrote:
On Sat, 2012-08-18 at 16:10 +0400, Denis Efremov wrote:
Use rcu_dereference_protected in order to prevent lockdep
complaint. Sequel of the patch 863555be
Found by Linux Driver Verification project (linuxtesting.org).
On May 16, 2014, at 2:43 PM, Andi Kleen a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
ixgbe_read_reg and ixgbe_write_reg are frequently called and are very big
because they have complex error handling code.
Actually, this patch doesn't do anything to ixgbe_write_reg,
On May 19, 2014, at 4:25 PM, Andi Kleen a...@linux.intel.com wrote:
On Mon, May 19, 2014 at 10:00:52PM +, Rustad, Mark D wrote:
On May 16, 2014, at 2:43 PM, Andi Kleen a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
ixgbe_read_reg and ixgbe_write_reg are frequently
On Jun 4, 2014, at 2:55 PM, Joe Perches j...@perches.com wrote:
On Wed, 2014-06-04 at 23:29 +0200, Rickard Strandqvist wrote:
Added a guaranteed null-terminate after call to strncpy.
Perhaps all of these should be strlcpy
The code that is there seems fine. The length of the array exceeds
The warning appears in W=2 builds. I had another way to silence it by using
diagnostic control macros, but those macros were not accepted. Using a single
designated initialization also silences it.
Sent from my iPhone
On Oct 17, 2014, at 8:26 AM, Christoph Hellwig h...@infradead.org wrote:
On Oct 21, 2014, at 12:07 PM, Andrew Morton a...@linux-foundation.org wrote:
On Sat, 18 Oct 2014 17:39:10 -0700 ebied...@xmission.com (Eric W. Biederman)
wrote:
Jeff Kirsher jeffrey.t.kirs...@intel.com writes:
From: Mark Rustad mark.d.rus...@intel.com
Resolve
On Sep 4, 2014, at 2:38 PM, Andrew Morton a...@linux-foundation.org wrote:
From: Mark Rustad mark.d.rus...@intel.com
Resolve a shadow warning in W=2 builds arising from min/max macro
references in a parameter to a min3/max3 macro. There is no
functional issue - the warning is benign - but
On Sep 12, 2014, at 3:40 PM, Andrew Morton a...@linux-foundation.org wrote:
On Thu, 11 Sep 2014 23:39:36 +0200 Michal Nazarewicz min...@mina86.com
wrote:
Because min and max macros use the same variable names no matter
how many times they are called (or how deep the nesting of their
Michal,
On Sep 12, 2014, at 4:37 PM, Michal Nazarewicz min...@mina86.com wrote:
On Fri, Sep 12 2014, Andrew Morton a...@linux-foundation.org wrote:
On Thu, 11 Sep 2014 23:39:36 +0200 Michal Nazarewicz min...@mina86.com
wrote:
Because min and max macros use the same variable names no
On Sep 19, 2014, at 12:34 PM, Richard Weinberger richard.weinber...@gmail.com
wrote:
On Fri, Sep 19, 2014 at 5:29 PM, Jeff Kirsher
jeffrey.t.kirs...@intel.com wrote:
From: Mark Rustad mark.d.rus...@intel.com
Use diagnostic control macros to ignore nested-externs warnings
in this case.
On Sep 19, 2014, at 1:41 PM, Richard Weinberger rich...@nod.at wrote:
Am 19.09.2014 22:34, schrieb Rustad, Mark D:
Excellent. I'll try adding an include of delayacct.h instead. My patch was
based on the assumption that the existing code was wanted in that form for
some reason, so the patch
On Sep 19, 2014, at 2:21 PM, Josh Triplett j...@joshtriplett.org wrote:
On Fri, Sep 19, 2014 at 07:20:30PM +0200, Oleg Nesterov wrote:
On 09/19, Richard Weinberger wrote:
Am 19.09.2014 17:37, schrieb Jeff Kirsher:
See patch 1 of the series.
I was not CC'ed...
Me too, and thus I
On Sep 19, 2014, at 3:54 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Sep 19, 2014 at 08:29:40AM -0700, Jeff Kirsher wrote:
From: Mark Rustad mark.d.rus...@intel.com
Use diagnostic control macros to ignore nested-externs warnings
in this case.
CC: Ingo Molnar mi...@redhat.com
On Sep 22, 2014, at 8:33 AM, Borislav Petkov b...@alien8.de wrote:
On Fri, Sep 19, 2014 at 08:29:33AM -0700, Jeff Kirsher wrote:
The following patches silence over 100,000 warnings in a W=2
kernel build. This series does most of it by using the compilers
diagnostic controls. The first patch
On Sep 22, 2014, at 11:40 AM, Borislav Petkov b...@alien8.de wrote:
On Mon, Sep 22, 2014 at 05:06:27PM +, Rustad, Mark D wrote:
Well, the whole series of patches that I made definitely went too far
- only the first 5 out of about 30 have been posted, but if we can
make some progress
On Sep 22, 2014, at 12:01 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
Avoid W=2 nested-externs warning by moving the nested extern to
a normal extern. This eliminates that warning which is generated
for every inclusion of
On Sep 22, 2014, at 1:05 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 07:32:04PM +, Rustad, Mark D wrote:
I assume that nested-externs is included in W=2 because many uses of
them, especially with function prototypes, creates a risk of inconsistent
declarations
On Sep 22, 2014, at 1:33 PM, Borislav Petkov b...@alien8.de wrote:
Btw, out of curiosity, what is your use case for staring at those W=2
warnings?
I know no one cares about out-of-tree drivers, but I have a hack that
allows building out-of-tree drivers without getting warnings from the
kernel
On Sep 22, 2014, at 2:21 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
Because I have found that enabling many warnings helps identify problems
in code and it has been my standard practice since about 1999 to do so.
The compiler
On Aug 31, 2014, at 5:52 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Jeff Kirsher jeffrey.t.kirs...@intel.com writes:
From: Mark Rustad mark.d.rus...@intel.com
Resolve a missing-field-initializer warning, that is produced
by every reference to module_param_call, by using designated
On Sep 1, 2014, at 4:41 PM, Jeff Kirsher jeffrey.t.kirs...@intel.com wrote:
On Mon, 2014-09-01 at 14:02 +0200, Peter Zijlstra wrote:
On Thu, Aug 28, 2014 at 05:19:26AM -0700, Jeff Kirsher wrote:
From: Mark Rustad mark.d.rus...@intel.com
Resolve some shadow warnings resulting from using the
On Sep 25, 2014, at 12:45 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote:
Instead of grepping, you can feed the build log to linux-log-summary.
Or when changing a driver, feed the before and after build logs to
linux-log-diff. That way you won't miss the single new warning you've
just
On Sep 26, 2014, at 12:58 PM, j...@joshtriplett.org j...@joshtriplett.org
wrote:
On Fri, Sep 26, 2014 at 07:37:19PM +, Rustad, Mark D wrote:
Most of the others come from null-entry table initializations, i.e. {
0 }, which give missing field initializer warnings.
I'd suggest
On Sep 23, 2014, at 7:49 AM, Josh Triplett j...@joshtriplett.org wrote:
On Tue, Sep 23, 2014 at 10:01:20AM +0200, Borislav Petkov wrote:
./arch/x86/include/asm/io_apic.h: In function ‘io_apic_modify’:
./arch/x86/include/asm/io_apic.h:223:48: warning: declaration of ‘apic’
shadows a global
On Sep 23, 2014, at 1:22 AM, Borislav Petkov b...@alien8.de wrote:
On Mon, Sep 22, 2014 at 09:50:54PM +, Rustad, Mark D wrote:
* Fixing those is a good idea if the fixes are clean - I think we all
agree by now that adding code just to shut up gcc is not nice.
Yes, but I think
On Sep 23, 2014, at 11:44 AM, Borislav Petkov b...@alien8.de wrote:
On Tue, Sep 23, 2014 at 05:24:22PM +, Rustad, Mark D wrote:
Yes, but I think there are a few cases where it could be helpful. When
there is something exceptional that will throw a warning. In one of the
patches that Jeff
On Sep 23, 2014, at 11:44 AM, Borislav Petkov b...@alien8.de wrote:
Again, we should take compiler warnings with a grain of salt and judge
them only by the quality of the generated code. IMO.
The more I thought about this, the more I think it argues for having some
diagnostic control macros.
On Nov 4, 2014, at 7:52 AM, Steven Rostedt rost...@goodmis.org wrote:
From: Steven Rostedt (Red Hat) rost...@goodmis.org
To allow for the restructiong of the trace_seq code, we need users
of it to use the helper functions instead of accessing the internals
of the trace_seq structure itself.
On Nov 4, 2014, at 11:35 AM, Steven Rostedt rost...@goodmis.org wrote:
On Tue, 4 Nov 2014 14:09:54 -0500
Steven Rostedt rost...@goodmis.org wrote:
On Tue, 4 Nov 2014 17:17:08 +
Rustad, Mark D mark.d.rus...@intel.com wrote:
On Nov 4, 2014, at 7:52 AM, Steven Rostedt rost
On Dec 10, 2014, at 10:28 AM, Joe Perches j...@perches.com wrote:
Making things const is a good thing.
(x86-64 defconfig with all irda)
$ size net/irda/built-in.o*
text data bss dec hex filename
109276 1868 244 111388 1b31c net/irda/built-in.o.new
On Feb 11, 2015, at 2:51 PM, Rasmus Villemoes li...@rasmusvillemoes.dk wrote:
Since these fmt_* variables are just const char*, and not const
char[], gcc (and smatch) doesn't to type checking of the arguments to
the printf functions. Since the linker knows perfectly well to merge
identical
Gerry,
On Aug 9, 2015, at 1:15 AM, Jiang Liu jiang@linux.intel.com wrote:
Alex Deucher, Mark Rustad and Alexander Holler reported a regression
with the latest v4.2-rc4 kernel, which breaks some SATA controllers.
With multi-MSI capable SATA controllers, only the first port works,
all
Nicholas Krause wrote:
> This fixes error handling in the function fm10k_setup_tc to properly
> check if the call to the function fm10k_open has failed by returning
> a error and if so return immediately to the caller of the function
> fm10k_setup_tc to properly signal this
Ben Hutchings wrote:
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -176,6 +176,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
> /* Provide indication device is assigned by a Virtual Machine Manager */
>
Ben Hutchings wrote:
> They're bit masks, not bit numbers, both in 3.2 and upstream. In
> mainline, bits 3-7 have already been assigned to other flags. I don't
> see the need to renumber or write the value differently when
> backporting.
No problem. I just saw the
> On Sep 4, 2015, at 2:07 AM, David Laight wrote:
>
>> I find them useful as syntactic sugar. We have not used them a lot, but
>> there are cases in our crypto
>> handling code where we have fixed size array inputs/outputs and there we
>> opted to use them. They make
> On Sep 7, 2015, at 4:02 AM, David Laight wrote:
>
> Feed:
> int bar(int (*f)[10]) { return sizeof *f; }
> into cc -O2 -S and look at the generated code - returns 40 not 4.
Yes, indeed it does. And with clang too. I guess I was too easily discouraged
when looking for
> On Sep 9, 2015, at 9:07 PM, Jarod Wilson wrote:
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index e174fbb..a5e0022 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++
> On Sep 11, 2015, at 6:11 PM, Rustad, Mark D <mark.d.rus...@intel.com> wrote:
>
> Superficially this looks pretty good. I need to think harder to be sure of
> the details.
This is the first time I've looked at all at any of the vfio code, but this is
still looking
Alex,
> On Sep 11, 2015, at 11:16 AM, Alex Williamson
> wrote:
>
> RFC - Is this something we should do?
Superficially this looks pretty good. I need to think harder to be sure of the
details.
> Should we consider providing
> similar emulation through PCI sysfs
> On Sep 29, 2015, at 3:39 PM, Joe Stringer wrote:
>
> @@ -728,8 +727,14 @@ static void ovs_fragment(struct vport *vport, struct
> sk_buff *skb, u16 mru,
> WARN_ONCE(1, "Failed fragment ->%s: eth=%04x, MRU=%d, MTU=%d.",
>
> On Sep 15, 2015, at 9:24 PM, Alex Williamson
> wrote:
>
> When we quirk a device with PCI_DEV_FLAGS_VPD_REF_F0 we're expecting
> to find a device where all the functions are identical. If we don't
> find that, we don't make VPD accessible through pci_vpd_ops.
> On Sep 15, 2015, at 10:17 AM, Alex Williamson
> wrote:
>
> Commit 932c435caba8 ("PCI: Add dev_flags bit to access VPD through
> function 0") passes PCI_SLOT(devfn) for the devfn parameter of
> pci_get_slot(). Generally this works because we're fairly well
>
> On Sep 24, 2015, at 11:27 AM, Bjorn Helgaas wrote:
>
> Applied to for-linus for v4.3 with acks from Myron & Mark, thanks!
>
> I removed the stable tag because 932c435caba8 first appeared in
> v4.3-rc1, so it shouldn't appear in any stable kernels yet. Right?
I have seen
> On Sep 18, 2015, at 1:11 AM, Jiri Slaby wrote:
>
> On 09/15/2015, 06:12 PM, Shuah Khan wrote:
>>
>>
>> Jiri,
>>
>> I am seeing problems during PCI scans with this patch. I had
>> to boot it in recovery mode once and it is booting fine after
>> that, however, this is a
Andy Shevchenko wrote:
On Mon, Apr 11, 2016 at 6:27 PM, Sudip Mukherjee
wrote:
From: Sudip Mukherjee
We have a check for card just after dereferencing it. So if it is NULL
we have already dereferenced
Denys Vlasenko wrote:
Users report that under VMWare, er32(TIMINCA) returns zero.
This causes division by zero at init time as follows:
==>incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS;
Some comments below:
K. Y. Srinivasan wrote:
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan
---
KY Srinivasan <k...@microsoft.com> wrote:
-Original Message-
From: Rustad, Mark D [mailto:mark.d.rus...@intel.com]
Sent: Thursday, April 14, 2016 4:01 PM
To: KY Srinivasan <k...@microsoft.com>
Cc: David Miller <da...@davemloft.net>; netdev
<net...@vger.kern
KY Srinivasan <k...@microsoft.com> wrote:
-Original Message-
From: Rustad, Mark D [mailto:mark.d.rus...@intel.com]
Sent: Thursday, April 14, 2016 5:07 PM
To: KY Srinivasan <k...@microsoft.com>
Cc: David Miller <da...@davemloft.net>; netdev
<net...@vger.kern
Jarod Wilson wrote:
I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used
as a PTP slave experiences random ~10 hour clock jumps, which are resolved
if the same workaround for the 82574 and 82583 is employed. Switching from
an if to a select, because the
Benjamin Herrenschmidt wrote:
We may want some kind of "strict" vs. "relaxed" model here to
differenciate the desktop user wanting to give a function to his/her
windows partition and doesn't care about strict isolation vs. the cloud
data center.
I don't think
Benjamin Herrenschmidt wrote:
Filtering things to work around bugs in existing guests to avoid crashes
is a different kettle of fish and could be justified but keep in mind that
in most cases a malicious guest will be able to exploit those HW flaws.
Bugs in existing
Greg wrote:
Someday Linux will be a modern OS that just includes IPV6 and forces a
config option to NOT have it.
That'll be great. All the IS_ENABLED_(CONFIG_IPV6) scattered everywhere
is nuts.
Better wait until everyone at least *has* IPv6! I have yet to have IPv6
Zhouyi Zhou wrote:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index fee1f29..4926d48 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -2173,8
On Mar 12, 2017, at 7:02 PM, Kees Cook wrote:
> Are there nominations for most comprehensive changelog of the year? :)
> This is awesome.
Especially for a one-liner! Truly comprehensive and completely relevant.
--
Mark Rustad, Networking Division, Intel Corporation
> On Jul 23, 2017, at 10:05 AM, Florian Fainelli wrote:
>> +
>> +strncpy(drvinfo->version, HNAE_DRIVER_VERSION,
>> +sizeof(drvinfo->version));
>> +drvinfo->version[sizeof(drvinfo->version) - 1] = '\0';
>
> strlcpy() would probably do that for you.
You
> On Sep 27, 2017, at 9:39 AM, Grant Grundler wrote:
>
> On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum wrote:
>> Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson:
>>>
>>> I know that for at least some of the adapters in the CDC Ethernet
> On Sep 29, 2017, at 3:22 AM, Jason A. Donenfeld wrote:
>
> Hi guys,
>
> One handy aspect of Netlink is that it's backwards compatible. This
> means that you can run old userspace utilities on new kernels, even if
> the new kernel supports new features and netlink attributes.
> On Feb 22, 2018, at 10:26 AM, Christoph Hellwig wrote:
>
> Can we move this into common code as a a generic_sriov_configure
> helper? Nothing is really virtio specific, and it seems like
> some other drivers could also use it, e.g. ena or nvme.
That seems like a good idea
Alex,
> On Feb 26, 2018, at 7:26 AM, Alexander Duyck
> wrote:
>
> Mark,
>
> In the future please don't put my "Reviewed-by" on a patch that I
> haven't reviewed. I believe I reviewed one of the earlier patches, but
> I hadn't reviewed this version.
I'm very sorry.
On Mar 15, 2018, at 11:42 AM, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Hardware-realized virtio_pci devices can implement SR-IOV, so this
> patch enables its use. The device in question is an upcoming Intel
> NIC that implements
On Mar 15, 2018, at 11:41 AM, Alexander Duyck wrote:
> From: Alexander Duyck
>
> This patch adds a common configuration function called
> pci_sriov_configure_simple that will allow for managing VFs on devices
> where the PF is not capable
On Apr 3, 2018, at 11:27 AM, Michael S. Tsirkin wrote:
I'm not sure why you would need a feature bit. The capability is
controlled via PCI configuration space. If it is present the device
has the capability. If it is not then it does not.
Basically if the PCI configuration
> On Feb 27, 2018, at 7:35 AM, David Miller wrote:
>
> I don't like these helpers on many different levels.
> So kill off pci_sriov_enable() helper completely, it is unnecessary,
> and rename the disable helper so that it says something meaningful to
> the reader.
Yes.
On Apr 8, 2013, at 8:45 AM, Michael Riesch wrote:
>
> Signed-off-by: Michael Riesch
> Cc: "David S. Miller"
> Cc: Greg Kroah-Hartman
> Cc: Jiri Benc
> Cc: "Theodore Ts'o"
> Cc: linux-kernel@vger.kernel.org
> ---
> Habidere,
>
> I encountered a netlink kernel warning when running avahi
On Jun 4, 2014, at 2:55 PM, Joe Perches wrote:
> On Wed, 2014-06-04 at 23:29 +0200, Rickard Strandqvist wrote:
>> Added a guaranteed null-terminate after call to strncpy.
>
> Perhaps all of these should be strlcpy
The code that is there seems fine. The length of the array exceeds the length
On May 16, 2014, at 2:43 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> ixgbe_read_reg and ixgbe_write_reg are frequently called and are very big
> because they have complex error handling code.
Actually, this patch doesn't do anything to ixgbe_write_reg, which would almost
certainly be very
On May 19, 2014, at 4:25 PM, Andi Kleen wrote:
> On Mon, May 19, 2014 at 10:00:52PM +0000, Rustad, Mark D wrote:
>> On May 16, 2014, at 2:43 PM, Andi Kleen wrote:
>>
>>> From: Andi Kleen
>>>
>>> ixgbe_read_reg and ixgbe_write_reg are frequently cal
On Mar 15, 2018, at 11:41 AM, Alexander Duyck wrote:
> From: Alexander Duyck
>
> This patch adds a common configuration function called
> pci_sriov_configure_simple that will allow for managing VFs on devices
> where the PF is not capable of managing VF resources.
>
> Signed-off-by: Alexander
On Mar 15, 2018, at 11:42 AM, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Hardware-realized virtio_pci devices can implement SR-IOV, so this
> patch enables its use. The device in question is an upcoming Intel
> NIC that implements both a virtio_net PF and virtio_net VFs. These
> are
> On Feb 22, 2018, at 10:26 AM, Christoph Hellwig wrote:
>
> Can we move this into common code as a a generic_sriov_configure
> helper? Nothing is really virtio specific, and it seems like
> some other drivers could also use it, e.g. ena or nvme.
That seems like a good idea to me, especially
> On Jul 23, 2017, at 10:05 AM, Florian Fainelli wrote:
>> +
>> +strncpy(drvinfo->version, HNAE_DRIVER_VERSION,
>> +sizeof(drvinfo->version));
>> +drvinfo->version[sizeof(drvinfo->version) - 1] = '\0';
>
> strlcpy() would probably do that for you.
You need to be careful
> On Sep 27, 2017, at 9:39 AM, Grant Grundler wrote:
>
> On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum wrote:
>> Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson:
>>>
>>> I know that for at least some of the adapters in the CDC Ethernet
>>> blacklist it was claimed that the
> On Sep 29, 2017, at 3:22 AM, Jason A. Donenfeld wrote:
>
> Hi guys,
>
> One handy aspect of Netlink is that it's backwards compatible. This
> means that you can run old userspace utilities on new kernels, even if
> the new kernel supports new features and netlink attributes. The wire
>
On Apr 3, 2018, at 11:27 AM, Michael S. Tsirkin wrote:
I'm not sure why you would need a feature bit. The capability is
controlled via PCI configuration space. If it is present the device
has the capability. If it is not then it does not.
Basically if the PCI configuration space is not
Alex,
> On Feb 26, 2018, at 7:26 AM, Alexander Duyck
> wrote:
>
> Mark,
>
> In the future please don't put my "Reviewed-by" on a patch that I
> haven't reviewed. I believe I reviewed one of the earlier patches, but
> I hadn't reviewed this version.
I'm very sorry. I completely spaced doing
> On Feb 27, 2018, at 7:35 AM, David Miller wrote:
>
> I don't like these helpers on many different levels.
> So kill off pci_sriov_enable() helper completely, it is unnecessary,
> and rename the disable helper so that it says something meaningful to
> the reader.
Yes. Once pointed out, I
On Aug 18, 2012, at 3:35 PM, Nicholas A. Bellinger wrote:
> On Sat, 2012-08-18 at 16:10 +0400, Denis Efremov wrote:
>> Use rcu_dereference_protected in order to prevent lockdep
>> complaint. Sequel of the patch 863555be
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>>
On Sep 25, 2014, at 12:45 AM, Geert Uytterhoeven wrote:
> Instead of grepping, you can feed the build log to linux-log-summary.
> Or when changing a driver, feed the before and after build logs to
> linux-log-diff. That way you won't miss the single new warning you've
> just introduced.
>
>
On Sep 26, 2014, at 12:58 PM,
wrote:
> On Fri, Sep 26, 2014 at 07:37:19PM +0000, Rustad, Mark D wrote:
>> Most of the others come from null-entry table initializations, i.e. {
>> 0 }, which give missing field initializer warnings.
>
> I'd suggest that such ini
On Dec 10, 2014, at 10:28 AM, Joe Perches wrote:
> Making things const is a good thing.
>
> (x86-64 defconfig with all irda)
> $ size net/irda/built-in.o*
> text data bss dec hex filename
> 109276 1868 244 111388 1b31c net/irda/built-in.o.new
> 108828
On Sep 19, 2014, at 12:34 PM, Richard Weinberger
wrote:
> On Fri, Sep 19, 2014 at 5:29 PM, Jeff Kirsher
> wrote:
>> From: Mark Rustad
>>
>> Use diagnostic control macros to ignore nested-externs warnings
>> in this case.
>>
>> CC: Ingo Molnar
>> CC: Peter Zijlstra
>> CC: Brian Norris
>>
On Sep 19, 2014, at 1:41 PM, Richard Weinberger wrote:
> Am 19.09.2014 22:34, schrieb Rustad, Mark D:
>> Excellent. I'll try adding an include of delayacct.h instead. My patch was
>> based on the assumption that the existing code was wanted in that form for
>> some reason
On Sep 19, 2014, at 2:21 PM, Josh Triplett wrote:
> On Fri, Sep 19, 2014 at 07:20:30PM +0200, Oleg Nesterov wrote:
>> On 09/19, Richard Weinberger wrote:
>>>
>>> Am 19.09.2014 17:37, schrieb Jeff Kirsher:
See patch 1 of the series.
>>>
>>> I was not CC'ed...
>>
>> Me too, and thus
On Sep 19, 2014, at 3:54 PM, Peter Zijlstra wrote:
> On Fri, Sep 19, 2014 at 08:29:40AM -0700, Jeff Kirsher wrote:
>> From: Mark Rustad
>>
>> Use diagnostic control macros to ignore nested-externs warnings
>> in this case.
>>
>> CC: Ingo Molnar
>> CC: Peter Zijlstra
>> CC: Brian Norris
>>
On Sep 22, 2014, at 8:33 AM, Borislav Petkov wrote:
> On Fri, Sep 19, 2014 at 08:29:33AM -0700, Jeff Kirsher wrote:
>> The following patches silence over 100,000 warnings in a W=2
>> kernel build. This series does most of it by using the compilers
>> diagnostic controls. The first patch in the
On Sep 22, 2014, at 11:40 AM, Borislav Petkov wrote:
> On Mon, Sep 22, 2014 at 05:06:27PM +0000, Rustad, Mark D wrote:
>> Well, the whole series of patches that I made definitely went too far
>> - only the first 5 out of about 30 have been posted, but if we can
>&g
On Sep 22, 2014, at 12:01 PM, Peter Zijlstra wrote:
> On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
>> Avoid W=2 nested-externs warning by moving the nested extern to
>> a normal extern. This eliminates that warning which is generated
>> for every inclusion of sched.h in a
On Sep 22, 2014, at 1:05 PM, Peter Zijlstra wrote:
> On Mon, Sep 22, 2014 at 07:32:04PM +0000, Rustad, Mark D wrote:
>> I assume that nested-externs is included in W=2 because many uses of
>> them, especially with function prototypes, creates a risk of inconsistent
>> dec
On Sep 22, 2014, at 1:33 PM, Borislav Petkov wrote:
> Btw, out of curiosity, what is your use case for staring at those W=2
> warnings?
I know no one cares about out-of-tree drivers, but I have a hack that
allows building out-of-tree drivers without getting warnings from the
kernel includes. We
On Sep 22, 2014, at 2:21 PM, Peter Zijlstra wrote:
> On Mon, Sep 22, 2014 at 08:59:32PM +0000, Rustad, Mark D wrote:
>> Because I have found that enabling many warnings helps identify problems
>> in code and it has been my standard practice since about 1999 to do so.
>>
On Sep 23, 2014, at 7:49 AM, Josh Triplett wrote:
> On Tue, Sep 23, 2014 at 10:01:20AM +0200, Borislav Petkov wrote:
>> ./arch/x86/include/asm/io_apic.h: In function ‘io_apic_modify’:
>> ./arch/x86/include/asm/io_apic.h:223:48: warning: declaration of ‘apic’
>> shadows a global declaration
On Sep 23, 2014, at 1:22 AM, Borislav Petkov wrote:
> On Mon, Sep 22, 2014 at 09:50:54PM +0000, Rustad, Mark D wrote:
> * Fixing those is a good idea if the fixes are clean - I think we all
> agree by now that adding code just to shut up gcc is not nice.
Yes, but I think there are a
On Sep 23, 2014, at 11:44 AM, Borislav Petkov wrote:
> On Tue, Sep 23, 2014 at 05:24:22PM +0000, Rustad, Mark D wrote:
>> Yes, but I think there are a few cases where it could be helpful. When
>> there is something exceptional that will throw a warning. In one of the
>> patc
On Aug 31, 2014, at 5:52 PM, Rusty Russell wrote:
> Jeff Kirsher writes:
>> From: Mark Rustad
>>
>> Resolve a missing-field-initializer warning, that is produced
>> by every reference to module_param_call, by using designated
>> initialization for the first field. That is enough to silence
>>
On Sep 1, 2014, at 4:41 PM, Jeff Kirsher wrote:
> On Mon, 2014-09-01 at 14:02 +0200, Peter Zijlstra wrote:
>> On Thu, Aug 28, 2014 at 05:19:26AM -0700, Jeff Kirsher wrote:
>>> From: Mark Rustad
>>>
>>> Resolve some shadow warnings resulting from using the name
>>> jiffies, which is a
On Sep 4, 2014, at 2:38 PM, Andrew Morton wrote:
>> From: Mark Rustad
>>
>> Resolve a shadow warning in W=2 builds arising from min/max macro
>> references in a parameter to a min3/max3 macro. There is no
>> functional issue - the warning is benign - but simply changing
>> some local variable
On Sep 23, 2014, at 11:44 AM, Borislav Petkov wrote:
> Again, we should take compiler warnings with a grain of salt and judge
> them only by the quality of the generated code. IMO.
The more I thought about this, the more I think it argues for having some
diagnostic control macros. Tools such as
1 - 100 of 132 matches
Mail list logo