Re: [PATCH] rtnetlink: Call nlmsg_parse() with correct header length

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:

Re: [PATCH] tcm_fc: rcu_deref outside rcu lock/unlock section

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).

Re: [PATCH 1/8] ixgbe: Out of line ixgbe_read/write_reg

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,

Re: [PATCH 1/8] ixgbe: Out of line ixgbe_read/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

Re: [E1000-devel] [PATCH] net: ethernet: intel: ixgbe: ixgbe_main.c: Cleaning up missing null-terminate after strncpy call

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

Re: [PATCH] scsi: Resolve some missing-field-initializers warnings

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:

Re: [PATCH] kernel/sysctl: Resolve missing-field-initializers warnings

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

Re: kernel: Resolve a shadow warning

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

Re: [PATCH 2/2] kernel.h: use __COUNTER__ in min and max macros to avoid -Wshadow warnings

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

Re: [PATCH 2/2] kernel.h: use __COUNTER__ in min and max macros to avoid -Wshadow warnings

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

Re: [PATCH 7/7] sched: Silence nested-externs warnings

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.

Re: [PATCH 7/7] sched: Silence nested-externs warnings

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

Re: [PATCH 5/7] signal: Silence nested-externs warnings

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

Re: [PATCH 7/7] sched: Silence nested-externs warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH] sched: Remove nested extern

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

Re: [PATCH] sched: Remove nested extern

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH] sched: Remove nested extern

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

Re: [PATCH] moduleparam: Resolve missing-field-initializer warning

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

Re: [PATCH] semaphore: Resolve some shadow warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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.

Re: [RFC][PATCH 01/12 v3] x86/kvm/tracing: Use helper function trace_seq_buffer_ptr()

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.

Re: [RFC][PATCH 01/12 v3] x86/kvm/tracing: Use helper function trace_seq_buffer_ptr()

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

Re: [PATCH] irda: Convert function pointer arrays and uses to const

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

Re: [PATCH] iwl4965: Enable checking of format strings

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

Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7

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

Re: [Intel-wired-lan] [PATCH] fm10k:Fix error handling in the function fm10k_setup_tc

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

Re: [PATCH 3.2 035/107] PCI: Add dev_flags bit to access VPD through function 0

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 */ >

Re: [PATCH 3.2 035/107] PCI: Add dev_flags bit to access VPD through function 0

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

Re: [GIT] Networking

> 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

Re: [GIT] Networking

> 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

Re: [PATCH] igb: don't unmap hw_addr if its NULL

> 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 > +++

Re: [RFC PATCH] vfio/pci: Use kernel VPD access functions

> 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

Re: [RFC PATCH] vfio/pci: Use kernel VPD access functions

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

Re: [PATCH net 3/7] openvswitch: Fix skb leak in ovs_fragment()

> 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.", >

Re: [PATCH] PCI: Relax function 0 VPD test and relocate

> 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.

Re: [PATCH] PCI: Fix devfn for VPD access through function 0

> 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 >

Re: [PATCH] PCI: Fix devfn for VPD access through function 0

> 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

Re: [PATCH 3.12 00/33] 3.12.48-stable review

> 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

Re: [PATCH] mwifiex: fix possible NULL dereference

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

Re: [Intel-wired-lan] [PATCH] e1000e: prevent division by zero if TIMINCA is zero

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;

Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

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 ---

Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

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

Re: [PATCH net-next 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)

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

Re: [Intel-wired-lan] [PATCH net] e1000e: fix PTP on e1000_pch_lpt variants

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

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

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

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

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

Re: [PATCH v3] net: ip, diag -- Add diag interface for raw sockets

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

Re: [Intel-wired-lan] [PATCH 1/1] ixgbe: fcoe: return value of skb_linearize should be handled

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

Re: [PATCH] x86-32: fix tlb flushing when lguest clears PGE

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

Re: [PATCH V4 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

> 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

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

> 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

Re: netlink backwards compatibility in userspace tools

> 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.

Re: [RFC PATCH V2] virtio_pci: Add SR-IOV support

> 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

Re: [RFC PATCH V4] pci: virtio_pci: Add SR-IOV support for virtio_pci devices

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.

Re: [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

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

Re: [virtio-dev] [pci PATCH v7 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources

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

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

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

Re: [RFC PATCH V3] virtio_pci: Add SR-IOV support

> 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.

Re: [PATCH] rtnetlink: Call nlmsg_parse() with correct header length

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

Re: [E1000-devel] [PATCH] net: ethernet: intel: ixgbe: ixgbe_main.c: Cleaning up missing null-terminate after strncpy call

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

Re: [PATCH 1/8] ixgbe: Out of line ixgbe_read/write_reg

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

Re: [PATCH 1/8] ixgbe: Out of line ixgbe_read/write_reg

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

Re: [virtio-dev] [pci PATCH v7 1/5] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources

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

Re: [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

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

Re: [RFC PATCH V2] virtio_pci: Add SR-IOV support

> 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

Re: [PATCH V4 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver

> 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

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

> 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

Re: netlink backwards compatibility in userspace tools

> 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 >

Re: [virtio-dev] [pci PATCH v7 2/5] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices

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

Re: [RFC PATCH V4] pci: virtio_pci: Add SR-IOV support for virtio_pci devices

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

Re: [RFC PATCH V3] virtio_pci: Add SR-IOV support

> 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

Re: [PATCH] tcm_fc: rcu_deref outside rcu lock/unlock section

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). >> >>

Re: [PATCH 0/7] Silence even more W=2 warnings

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. > >

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH] irda: Convert function pointer arrays and uses to const

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

Re: [PATCH 7/7] sched: Silence nested-externs warnings

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 >>

Re: [PATCH 7/7] sched: Silence nested-externs warnings

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

Re: [PATCH 5/7] signal: Silence nested-externs warnings

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

Re: [PATCH 7/7] sched: Silence nested-externs warnings

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 >>

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH] sched: Remove nested extern

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

Re: [PATCH] sched: Remove nested extern

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH] sched: Remove nested extern

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. >>

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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

Re: [PATCH] moduleparam: Resolve missing-field-initializer warning

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 >>

Re: [PATCH] semaphore: Resolve some shadow warnings

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

Re: kernel: Resolve a shadow warning

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

Re: [PATCH 0/7] Silence even more W=2 warnings

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   2   >