[PATCH] ice: set the value of global config lock timeout longer

[Liwei Song]

It may need hold Global Config Lock a longer time when download DDP
package file, extend the timeout value to 5000ms to ensure that
download can be finished before other AQ command got time to run,
this will fix the issue below when probe the device, 5000ms is a test
value that work with both Backplane and BreakoutCable NVM image:

ice :f4:00.0: VSI 12 failed lan queue config, error ICE_ERR_CFG
ice :f4:00.0: Failed to delete VSI 12 in FW - error: ICE_ERR_AQ_TIMEOUT
ice :f4:00.0: probe failed due to setup PF switch: -12
ice: probe of :f4:00.0 failed with error -12

Signed-off-by: Liwei Song 
---
 drivers/net/ethernet/intel/ice/ice_type.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_type.h 
b/drivers/net/ethernet/intel/ice/ice_type.h
index 266036b7a49a..8a90c47e337d 100644
--- a/drivers/net/ethernet/intel/ice/ice_type.h
+++ b/drivers/net/ethernet/intel/ice/ice_type.h
@@ -63,7 +63,7 @@ enum ice_aq_res_ids {
 /* FW update timeout definitions are in milliseconds */
 #define ICE_NVM_TIMEOUT18
 #define ICE_CHANGE_LOCK_TIMEOUT1000
-#define ICE_GLOBAL_CFG_LOCK_TIMEOUT3000
+#define ICE_GLOBAL_CFG_LOCK_TIMEOUT5000
 
 enum ice_aq_res_access_type {
ICE_RES_READ = 1,
-- 
2.17.1

Re: [PATCH] tools/power turbostat: call pread64 in kernel directly

[Liwei Song]

On 8/24/20 04:54, Alexander Monakov wrote:
> Hi,
> 
> I am not the original submitter, but I have answers and a proper patch :)
> 
> On Fri, 21 Aug 2020, Len Brown wrote:
> 
>> Re: offset size
>>
>> The offsets on this file are the MSR offsets.
>> What MSR are you trying to access at offset 0xc0010299?
> 
> This MSR is particular is part of AMD RAPL (energy measurements) interface.
> 
>> Re: pread vs pread64
>>
>> If I take on faith that you have some kind of 32-bit execution
>> environment that makes pread into pread32 instead of pread64, and that
>> truncates an off_t to 32-bits from 64-bits, and it actually makes
>> sense to request a read at this large offset...
> 
> The problem here stems from the backward compatibility in Glibc: off_t is
> 32-bit on 32-bit x86, unless compiled with -D_FILE_OFFSET_BITS=64. This
> macro should be used for all new code. Distros should enable it for all
> builds, but when one builds turbostat 'by hand', they hit the issue.
> 
>> would we really have to invoke syscall() directly -- couldn't we
>> invoke pread64() directly? (eg. below)
> 
> No, the proper fix is to pass -D_FILE_OFFSET_BITS=64 to the compiler.
> 
> Here's the patch:

This path works with my case.

Thanks,
Liwei.


> 
> ---8<---
> 
> From: Alexander Monakov 
> Date: Sun, 23 Aug 2020 23:27:02 +0300
> Subject: [PATCH] turbostat: build with _FILE_OFFSET_BITS=64
> 
> For compatibility reasons, Glibc off_t is a 32-bit type on 32-bit x86
> unless _FILE_OFFSET_BITS=64 is defined. Add this define, as otherwise
> reading MSRs with index 0x8000 and above attempts a pread with a
> negative offset, which fails.
> 
> Signed-off-by: Alexander Monakov 
> ---
>  tools/power/x86/turbostat/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/power/x86/turbostat/Makefile 
> b/tools/power/x86/turbostat/Makefile
> index 2b6551269e43..40ae44402eec 100644
> --- a/tools/power/x86/turbostat/Makefile
> +++ b/tools/power/x86/turbostat/Makefile
> @@ -12,6 +12,7 @@ turbostat : turbostat.c
>  override CFLAGS +=   -O2 -Wall -I../../../include
>  override CFLAGS +=   
> -DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"'
>  override CFLAGS +=   
> -DINTEL_FAMILY_HEADER='"../../../../arch/x86/include/asm/intel-family.h"'
> +override CFLAGS +=   -D_FILE_OFFSET_BITS=64
>  override CFLAGS +=   -D_FORTIFY_SOURCE=2
>  
>  %: %.c
> 

Re: [PATCH] tools/power turbostat: call pread64 in kernel directly

[Liwei Song]

with multilib lib32 support, the rootfs will be 32-bit, 
the kernel is still 64-bit, in this case run turbostat
will failed with "out of range" error.

Thanks,
Liwei.

On 8/14/20 05:43, Len Brown wrote:
> Huh?
> 
> On Fri, Jul 17, 2020 at 2:09 AM Liwei Song  wrote:
>>
>> with 32-bit rootfs, the offset may out of range when set it
>> to 0xc0010299, define it as "unsigned long long" type and
>> call pread64 directly in kernel.
>>
>> Signed-off-by: Liwei Song 
>> ---
>>  tools/power/x86/turbostat/turbostat.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/power/x86/turbostat/turbostat.c 
>> b/tools/power/x86/turbostat/turbostat.c
>> index 33b370865d16..4c5cdfcb5721 100644
>> --- a/tools/power/x86/turbostat/turbostat.c
>> +++ b/tools/power/x86/turbostat/turbostat.c
>> @@ -33,6 +33,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  char *proc_stat = "/proc/stat";
>>  FILE *outf;
>> @@ -381,11 +382,11 @@ int get_msr_fd(int cpu)
>> return fd;
>>  }
>>
>> -int get_msr(int cpu, off_t offset, unsigned long long *msr)
>> +int get_msr(int cpu, unsigned long long offset, unsigned long long *msr)
>>  {
>> ssize_t retval;
>>
>> -   retval = pread(get_msr_fd(cpu), msr, sizeof(*msr), offset);
>> +   retval = syscall(SYS_pread64, get_msr_fd(cpu), msr, sizeof(*msr), 
>> offset);
>>
>> if (retval != sizeof *msr)
>> err(-1, "cpu%d: msr offset 0x%llx read failed", cpu, 
>> (unsigned long long)offset);
>> --
>> 2.17.1
>>
> 
> 

Re: [PATCH] crypto: ccp - zero the cmd data after use it

[Liwei Song]

On 8/4/20 12:22, Herbert Xu wrote:
> On Tue, Aug 04, 2020 at 12:20:21PM +0800, Liwei Song wrote:
>>
>> Yes, the other process should do this zero work, but the case I met is
>> this address will appear in the slab_alloc_node() as freelist pointer of 
>> slub,
>> and before slub do zero wrok, even kzalloc() doesn't work with this address.
> 
> That would be memory corruption which has nothing to do with your
> patch.  If it is occurring then you should fix the place that is
> corrupting the memory and not work around it like this.

OK, understand, thanks for your suggestion.

Liwei.


> 
> Cheers,
> 

Re: [PATCH] crypto: ccp - zero the cmd data after use it

[Liwei Song]

On 8/4/20 12:04, Herbert Xu wrote:
> On Tue, Aug 04, 2020 at 11:51:47AM +0800, Liwei Song wrote:
>>
>> On 8/3/20 20:52, Herbert Xu wrote:
>>> On Mon, Aug 03, 2020 at 03:58:58PM +0800, Liwei Song wrote:
>>>> exist the following assignment in ccp(ignore the force
>>>> convert of the struct) by list_del in ccp_dequeue_cmd():
>>>> req->__ctx->cmd->entry->next = LIST_POISON1;
>>>>
>>>> after use the req, kzfree(req) can not zero the entry
>>>> entry->next = LIST_POISON1 of the ccp_cmd(cmd) struct
>>>> when this address available as slub freelist pointer, this will cause
>>>> the following "general protection fault" error if some process meet
>>>> this LIST_POISON1 value address when request memory:
>>>
>>> Your description makes no sense.  Please rewrite it and explain
>>> the problem properly.
>>
>> The problem here is that the entry of struct ccp_cmd is not zeroed after we 
>> use it,
>> If the other process got this address by kmalloc(), this illegal value 
>> "LIST_POISON1"
>> will cause "general protection fault" error.
> 
> If that's the case surely the other process should be zeroing
> the memory? Your explanation still makes no sense.

Yes, the other process should do this zero work, but the case I met is
this address will appear in the slab_alloc_node() as freelist pointer of slub,
and before slub do zero wrok, even kzalloc() doesn't work with this address.

Thanks,
Liwei.


> 
> Thanks,
> 

Re: [PATCH] crypto: ccp - zero the cmd data after use it

[Liwei Song]

On 8/3/20 20:52, Herbert Xu wrote:
> On Mon, Aug 03, 2020 at 03:58:58PM +0800, Liwei Song wrote:
>> exist the following assignment in ccp(ignore the force
>> convert of the struct) by list_del in ccp_dequeue_cmd():
>> req->__ctx->cmd->entry->next = LIST_POISON1;
>>
>> after use the req, kzfree(req) can not zero the entry
>> entry->next = LIST_POISON1 of the ccp_cmd(cmd) struct
>> when this address available as slub freelist pointer, this will cause
>> the following "general protection fault" error if some process meet
>> this LIST_POISON1 value address when request memory:
> 
> Your description makes no sense.  Please rewrite it and explain
> the problem properly.

The problem here is that the entry of struct ccp_cmd is not zeroed after we use 
it,
If the other process got this address by kmalloc(), this illegal value 
"LIST_POISON1"
will cause "general protection fault" error.

Thanks,
Liwei.


> 
> Thanks,
> 

[PATCH] crypto: ccp - zero the cmd data after use it

[Liwei Song]

exist the following assignment in ccp(ignore the force
convert of the struct) by list_del in ccp_dequeue_cmd():
req->__ctx->cmd->entry->next = LIST_POISON1;

after use the req, kzfree(req) can not zero the entry
entry->next = LIST_POISON1 of the ccp_cmd(cmd) struct
when this address available as slub freelist pointer, this will cause
the following "general protection fault" error if some process meet
this LIST_POISON1 value address when request memory:

general protection fault:  1 PREEMPT SMP NOPTI
CPU: 13 PID: 111282 Comm: msgstress03 Not tainted 5.2.45-yocto-standard #1
Hardware name: AMD Corporation Wallaby/Wallaby, BIOS WWB7713N 07/11/2017
RIP: 0010:__kmalloc_node+0x106/0x2f0
RSP: 0018:aa6dd83ffdc8 EFLAGS: 00010246
RAX:  RBX:  RCX: 0033e0cd
RDX: 0033e08d RSI: 0033e08d RDI: 0002c180
RBP: aa6dd83ffe00 R08: 00d4 R09: 966c9dc07180
R10: dead0100 R11:  R12: 0cc0
R13: 0100 R14:  R15: 966c9dc07180
FS: 7f83bb756600() GS:966c9e34() knlGS:
CS: 0010 DS:  ES:  CR0: 80050033
CR2: 7f83bb6917e0 CR3: 00080b794000 CR4: 003406e0
Call Trace:
? kvmalloc_node+0x7b/0x90
kvmalloc_node+0x7b/0x90
newque+0x32/0x1a0
ipcget+0x27a/0x2c0
ksys_msgget+0x51/0x70
__x64_sys_msgget+0x16/0x20
do_syscall_64+0x4d/0x130
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f83bb6917e7

Fix it by zero cmd struct after finished use it.

Signed-off-by: Liwei Song 
---
 drivers/crypto/ccp/ccp-dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index edefa669153f..75a6418d541d 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -409,6 +409,7 @@ static void ccp_do_cmd_complete(unsigned long data)
cmd->callback(cmd->data, cmd->ret);
 
complete(>completion);
+   memset(cmd, 0, sizeof(*cmd));
 }
 
 /**
-- 
2.17.1

[PATCH] tools/power turbostat: call pread64 in kernel directly

[Liwei Song]

with 32-bit rootfs, the offset may out of range when set it
to 0xc0010299, define it as "unsigned long long" type and
call pread64 directly in kernel.

Signed-off-by: Liwei Song 
---
 tools/power/x86/turbostat/turbostat.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 33b370865d16..4c5cdfcb5721 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 char *proc_stat = "/proc/stat";
 FILE *outf;
@@ -381,11 +382,11 @@ int get_msr_fd(int cpu)
return fd;
 }
 
-int get_msr(int cpu, off_t offset, unsigned long long *msr)
+int get_msr(int cpu, unsigned long long offset, unsigned long long *msr)
 {
ssize_t retval;
 
-   retval = pread(get_msr_fd(cpu), msr, sizeof(*msr), offset);
+   retval = syscall(SYS_pread64, get_msr_fd(cpu), msr, sizeof(*msr), 
offset);
 
if (retval != sizeof *msr)
err(-1, "cpu%d: msr offset 0x%llx read failed", cpu, (unsigned 
long long)offset);
-- 
2.17.1

Re: [PATCH] ALSA: hda: check RIRB to avoid use NULL pointer

[Liwei Song]

On 04/30/2019 04:53 PM, Takashi Iwai wrote:
> On Tue, 30 Apr 2019 10:32:47 +0200,
> Liwei Song wrote:
>>
>>
>>
>> On 04/30/2019 03:31 PM, Takashi Iwai wrote:
>>> On Tue, 30 Apr 2019 08:10:53 +0200,
>>> Song liwei wrote:
>>>>
>>>> From: Liwei Song 
>>>>
>>>> Fix the following BUG:
>>>>
>>>> BUG: unable to handle kernel NULL pointer dereference at 000c
>>>> Workqueue: events azx_probe_work [snd_hda_intel]
>>>> RIP: 0010:snd_hdac_bus_update_rirb+0x80/0x160 [snd_hda_core]
>>>> Call Trace:
>>>>  
>>>>  azx_interrupt+0x78/0x140 [snd_hda_codec]
>>>>  __handle_irq_event_percpu+0x49/0x300
>>>>  handle_irq_event_percpu+0x23/0x60
>>>>  handle_irq_event+0x3c/0x60
>>>>  handle_edge_irq+0xdb/0x180
>>>>  handle_irq+0x23/0x30
>>>>  do_IRQ+0x6a/0x140
>>>>  common_interrupt+0xf/0xf
>>>>
>>>> The Call Trace happened when run kdump on a NFS rootfs system.
>>>> Exist the following calling sequence when boot the second kernel:
>>>>
>>>> azx_first_init()
>>>>--> azx_acquire_irq()
>>>>   <-- interrupt come in, azx_interrupt() was called
>>>>--> hda_intel_init_chip()
>>>>   --> azx_init_chip()
>>>>  --> snd_hdac_bus_init_chip()
>>>>   --> snd_hdac_bus_init_cmd_io();
>>>> --> init rirb.buf and corb.buf
>>>>
>>>> Interrupt happened after azx_acquire_irq() while RIRB still didn't got
>>>> initialized, then NULL pointer will be used when process the interrupt.
>>>>
>>>> Check the value of RIRB to ensure it is not NULL, to aviod some special
>>>> case may hang the system.
>>>>
>>>> Fixes: 14752412721c ("ALSA: hda - Add the controller helper codes to 
>>>> hda-core module")
>>>> Signed-off-by: Liwei Song 
>>>
>>> Oh, that's indeed a race there.
>>>
>>> But I guess the check introduced by the patch is still error-prone.
>>> Basically the interrupt handling should be moved after the chip
>>> initialization.  I suppose that your platform uses the shared
>>> interrupt, not the MSI?
>>
>> This is the information from /proc/interrupt
>> 134:  0102  0  0  IR-PCI-MSI 514048-edge 
>>  snd_hda_intel:card0
> 
> Hm, then it's interesting...
> 
> 
>>> In anyway, alternative (and likely more certain) fix would be to move
>>> the azx_acquir_irq() call like the patch below (note: totally
>>> untested).  Could you check whether it works?
>>
>> Yes, It works.
>>
>> Considering a previous patch like the one you provide will import some 
>> issue, 
>> so I choose check the invalid value to low the risk, but just as you 
>> mentioned,
>> It is not a good solution.
>>
>> commit 542cedec53c9e8b73f3f05bf8468823598c50489
>> Author: Yu Zhao 
>> Date:   Tue Sep 11 15:12:46 2018 -0600
>>
>> Revert "ASoC: Intel: Skylake: Acquire irq after RIRB allocation"
>> 
>> This reverts commit 12eeeb4f4733bbc4481d01df35933fc15beb8b19.
>> 
>> The patch doesn't fix accessing memory with null pointer in
>> skl_interrupt().
>> 
>> There are two problems: 1) skl_init_chip() is called twice, before
>> and after dma buffer is allocate. The first call sets bus->chip_init
>> which prevents the second from initializing bus->corb.buf and
>> rirb.buf from bus->rb.area. 2) snd_hdac_bus_init_chip() enables
>> interrupt before snd_hdac_bus_init_cmd_io() initializing dma buffers.
>> There is a small window which skl_interrupt() can be called if irq
>> has been acquired. If so, it crashes when using null dma buffer
>> pointers.
> 
> Actually this followed by another fix b61749a89f82,
> sound: enable interrupt after dma buffer initialization
> 
> and this moved the IRQ enablement after snd_hdac_bus_init_cmd_io().
> 
> So I wonder how the irq gets triggered in your case.
> If it were a shared irq, it's understandable.  But for MSI, it should
> have been the isolated source.

I'm still working on how the irq was triggered,
it is a little complex to reproduce it, first it must run with NFS rootfs,
without NFS rootfs it can not reproduced.
Then with kdump enabled, after "echo c > /proc/sysrq-trigger" crash the kernel,
the kernel specified by kdump will boot, then interrupt will trigger
soon after azx interrupt was register.


> 
> In anyway, for the latest tree, the change I suggested would cover
> better although it's more radical as you pointed.

Got it, Thanks.

Liwei.


> 
> 
> thanks,
> 
> Takashi
> 
> 

Re: [PATCH] ALSA: hda: check RIRB to avoid use NULL pointer

[Liwei Song]

On 04/30/2019 03:31 PM, Takashi Iwai wrote:
> On Tue, 30 Apr 2019 08:10:53 +0200,
> Song liwei wrote:
>>
>> From: Liwei Song 
>>
>> Fix the following BUG:
>>
>> BUG: unable to handle kernel NULL pointer dereference at 000c
>> Workqueue: events azx_probe_work [snd_hda_intel]
>> RIP: 0010:snd_hdac_bus_update_rirb+0x80/0x160 [snd_hda_core]
>> Call Trace:
>>  
>>  azx_interrupt+0x78/0x140 [snd_hda_codec]
>>  __handle_irq_event_percpu+0x49/0x300
>>  handle_irq_event_percpu+0x23/0x60
>>  handle_irq_event+0x3c/0x60
>>  handle_edge_irq+0xdb/0x180
>>  handle_irq+0x23/0x30
>>  do_IRQ+0x6a/0x140
>>  common_interrupt+0xf/0xf
>>
>> The Call Trace happened when run kdump on a NFS rootfs system.
>> Exist the following calling sequence when boot the second kernel:
>>
>> azx_first_init()
>>--> azx_acquire_irq()
>>   <-- interrupt come in, azx_interrupt() was called
>>--> hda_intel_init_chip()
>>   --> azx_init_chip()
>>  --> snd_hdac_bus_init_chip()
>>   --> snd_hdac_bus_init_cmd_io();
>> --> init rirb.buf and corb.buf
>>
>> Interrupt happened after azx_acquire_irq() while RIRB still didn't got
>> initialized, then NULL pointer will be used when process the interrupt.
>>
>> Check the value of RIRB to ensure it is not NULL, to aviod some special
>> case may hang the system.
>>
>> Fixes: 14752412721c ("ALSA: hda - Add the controller helper codes to 
>> hda-core module")
>> Signed-off-by: Liwei Song 
> 
> Oh, that's indeed a race there.
> 
> But I guess the check introduced by the patch is still error-prone.
> Basically the interrupt handling should be moved after the chip
> initialization.  I suppose that your platform uses the shared
> interrupt, not the MSI?

This is the information from /proc/interrupt
134:  0102  0  0  IR-PCI-MSI 514048-edge  
snd_hda_intel:card0


> 
> In anyway, alternative (and likely more certain) fix would be to move
> the azx_acquir_irq() call like the patch below (note: totally
> untested).  Could you check whether it works?

Yes, It works.

Considering a previous patch like the one you provide will import some issue, 
so I choose check the invalid value to low the risk, but just as you mentioned,
It is not a good solution.

commit 542cedec53c9e8b73f3f05bf8468823598c50489
Author: Yu Zhao 
Date:   Tue Sep 11 15:12:46 2018 -0600

Revert "ASoC: Intel: Skylake: Acquire irq after RIRB allocation"

This reverts commit 12eeeb4f4733bbc4481d01df35933fc15beb8b19.

The patch doesn't fix accessing memory with null pointer in
skl_interrupt().

There are two problems: 1) skl_init_chip() is called twice, before
and after dma buffer is allocate. The first call sets bus->chip_init
which prevents the second from initializing bus->corb.buf and
rirb.buf from bus->rb.area. 2) snd_hdac_bus_init_chip() enables
interrupt before snd_hdac_bus_init_cmd_io() initializing dma buffers.
There is a small window which skl_interrupt() can be called if irq
has been acquired. If so, it crashes when using null dma buffer
pointers.

Thanks,
Liwei.


> 
> 
> thanks,
> 
> Takashi
> 
> 
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1788,9 +1788,6 @@ static int azx_first_init(struct azx *chip)
>   chip->msi = 0;
>   }
>  
> - if (azx_acquire_irq(chip, 0) < 0)
> - return -EBUSY;
> -
>   pci_set_master(pci);
>   synchronize_irq(bus->irq);
>  
> @@ -1904,6 +1901,9 @@ static int azx_first_init(struct azx *chip)
>   return -ENODEV;
>   }
>  
> + if (azx_acquire_irq(chip, 0) < 0)
> + return -EBUSY;
> +
>   strcpy(card->driver, "HDA-Intel");
>   strlcpy(card->shortname, driver_short_names[chip->driver_type],
>   sizeof(card->shortname));
> 
> 

[PATCH] edac: unregister the mci device before free the mci memory

[Liwei Song]

this patch can fix the following kmemleak:

unreferenced object 0x881022b60ee0 (size 32):
  comm "udevd", pid 262, jiffies 4294709066 (age 1410.265s)
  hex dump (first 32 bytes):
00 7c e8 18 10 88 ff ff 00 74 e8 18 10 88 ff ff .|...t..
00 70 e8 18 10 88 ff ff 00 00 00 00 00 00 00 00 .p..
  backtrace:
[] kmemleak_alloc+0x26/0x50
[] __kmalloc+0x154/0x2f0
[] edac_mc_alloc+0x278/0x6d0
[] 0xa0106f9d
[] local_pci_probe+0x3e/0x70
[] pci_device_probe+0x121/0x130
[] driver_probe_device+0x105/0x260
[] __driver_attach+0x93/0xa0
[] bus_for_each_dev+0x63/0xa0
[] driver_attach+0x1e/0x20
[] bus_add_driver+0x1f0/0x290
[] driver_register+0x64/0xf0
[] __pci_register_driver+0x4c/0x50
[] 0xa010d050
[] do_one_initcall+0x102/0x160
[] load_module+0x1a65/0x2230

The kmemleak happened when run "rmmod sb_edac.ko".
In edac_mc_free, only after mci device is ungistered, it will do the mci
free task, or it will do the mci unregister action, adjust the sequence
of the free task to ungister the device first and then free the mci
struct, then all memory allocated(Include dimms, csrows, channels)by
edac_mc_alloc() will got freed by edac_mc_free();

Because all allocated memory was freed by edac_mc_free() and the release
hook in edac_mc_sysfs.c can not release all allocated memory of EDAC MC,
so remove the free fragment from it to aviod duplicated memory free.

Signed-off-by: Liwei Song 
---
 drivers/edac/edac_mc.c   |  7 ---
 drivers/edac/edac_mc_sysfs.c | 12 
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index 7d3edd713932..12d9dc9cf85e 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -506,6 +506,10 @@ void edac_mc_free(struct mem_ctl_info *mci)
 {
edac_dbg(1, "\n");
 
+   /* the mci instance is freed here, when the sysfs object is dropped */
+   if (device_is_registered(>dev))
+   edac_unregister_sysfs(mci);
+
/* If we're not yet registered with sysfs free only what was allocated
 * in edac_mc_alloc().
 */
@@ -513,9 +517,6 @@ void edac_mc_free(struct mem_ctl_info *mci)
_edac_mc_free(mci);
return;
}
-
-   /* the mci instance is freed here, when the sysfs object is dropped */
-   edac_unregister_sysfs(mci);
 }
 EXPORT_SYMBOL_GPL(edac_mc_free);
 
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 20374b8248f0..20211b4ee2f1 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -276,10 +276,6 @@ static const struct attribute_group *csrow_attr_groups[] = 
{
 
 static void csrow_attr_release(struct device *dev)
 {
-   struct csrow_info *csrow = container_of(dev, struct csrow_info, dev);
-
-   edac_dbg(1, "Releasing csrow device %s\n", dev_name(dev));
-   kfree(csrow);
 }
 
 static const struct device_type csrow_attr_type = {
@@ -616,10 +612,6 @@ static const struct attribute_group *dimm_attr_groups[] = {
 
 static void dimm_attr_release(struct device *dev)
 {
-   struct dimm_info *dimm = container_of(dev, struct dimm_info, dev);
-
-   edac_dbg(1, "Releasing dimm device %s\n", dev_name(dev));
-   kfree(dimm);
 }
 
 static const struct device_type dimm_attr_type = {
@@ -892,10 +884,6 @@ static const struct attribute_group *mci_attr_groups[] = {
 
 static void mci_attr_release(struct device *dev)
 {
-   struct mem_ctl_info *mci = container_of(dev, struct mem_ctl_info, dev);
-
-   edac_dbg(1, "Releasing csrow device %s\n", dev_name(dev));
-   kfree(mci);
 }
 
 static const struct device_type mci_attr_type = {
-- 
2.7.4

Re: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

[Liwei Song]

On 07/31/2017 10:09 AM, Zheng, Lv wrote:
> Hi,
> 
>> From: linux-acpi-ow...@vger.kernel.org 
>> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Song
>> liwei
>> Subject: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware 
>> bug
>>
>> From: Liwei Song <liwei.s...@windriver.com>
>>
>> This is a follow up to commit f712c71f7b2b ("ACPI, APEI: Fixup common
>> access width firmware bug") fix the following firmware bug:
>>
>> [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]
>>
>> This is due to an 8-bit access width is specified for a 16-bit register,
>> Rearrange the condition and add 8-bit width check.
>>
>> Signed-off-by: Liwei Song <liwei.s...@windriver.com>
>> ---
>>  drivers/acpi/apei/apei-base.c | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
>> index da370e1..eca3d7a 100644
>> --- a/drivers/acpi/apei/apei-base.c
>> +++ b/drivers/acpi/apei/apei-base.c
>> @@ -604,12 +604,12 @@ static int apei_check_gar(struct acpi_generic_address 
>> *reg, u64 *paddr,
>>  *access_bit_width = 1UL << (access_size_code + 2);
>>
>>  /* Fixup common BIOS bug */
>> -if (bit_width == 32 && bit_offset == 0 && (*paddr & 0x03) == 0 &&
>> -*access_bit_width < 32)
>> -*access_bit_width = 32;
>> -else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 &&
>> -*access_bit_width < 64)
>> -*access_bit_width = 64;
>> +if (*access_bit_width < bit_width && bit_offset == 0) {
>> +if ((bit_width == 16 && (*paddr & 0x01) == 0) ||
>> +(bit_width == 32 && (*paddr & 0x03) == 0) ||
>> +(bit_width == 64 && (*paddr & 0x07) == 0))
>> +*access_bit_width = bit_width;
>> +}
>>
>>  if ((bit_width + bit_offset) > *access_bit_width) {
>>  pr_warning(FW_BUG APEI_PFX
> 
> IMO, such problem could also be fixed by this commit and a cleanup of APEI
> GAR code to invoke generic ACPICA GAR API - acpi_read()/acpi_write() directly.
> https://github.com/acpica/acpica/pull/209

Hi Lv,

I'm a bit confuse about the commit you said, do you mean this commit can also 
fix
this common 16-bit access width error, and will check-in to upstream kernel 
latter?
If so, please ignore this review.

Thanks,
Liwei.


> 
> Thanks and best regards
> Lv
> 
> 
> 

Re: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

[Liwei Song]

On 07/31/2017 10:09 AM, Zheng, Lv wrote:
> Hi,
> 
>> From: linux-acpi-ow...@vger.kernel.org 
>> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Song
>> liwei
>> Subject: [PATCH V2] ACPI, APEI: Fixup incorrect 16-bit access width firmware 
>> bug
>>
>> From: Liwei Song 
>>
>> This is a follow up to commit f712c71f7b2b ("ACPI, APEI: Fixup common
>> access width firmware bug") fix the following firmware bug:
>>
>> [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]
>>
>> This is due to an 8-bit access width is specified for a 16-bit register,
>> Rearrange the condition and add 8-bit width check.
>>
>> Signed-off-by: Liwei Song 
>> ---
>>  drivers/acpi/apei/apei-base.c | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
>> index da370e1..eca3d7a 100644
>> --- a/drivers/acpi/apei/apei-base.c
>> +++ b/drivers/acpi/apei/apei-base.c
>> @@ -604,12 +604,12 @@ static int apei_check_gar(struct acpi_generic_address 
>> *reg, u64 *paddr,
>>  *access_bit_width = 1UL << (access_size_code + 2);
>>
>>  /* Fixup common BIOS bug */
>> -if (bit_width == 32 && bit_offset == 0 && (*paddr & 0x03) == 0 &&
>> -*access_bit_width < 32)
>> -*access_bit_width = 32;
>> -else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 &&
>> -*access_bit_width < 64)
>> -*access_bit_width = 64;
>> +if (*access_bit_width < bit_width && bit_offset == 0) {
>> +if ((bit_width == 16 && (*paddr & 0x01) == 0) ||
>> +(bit_width == 32 && (*paddr & 0x03) == 0) ||
>> +(bit_width == 64 && (*paddr & 0x07) == 0))
>> +*access_bit_width = bit_width;
>> +}
>>
>>  if ((bit_width + bit_offset) > *access_bit_width) {
>>  pr_warning(FW_BUG APEI_PFX
> 
> IMO, such problem could also be fixed by this commit and a cleanup of APEI
> GAR code to invoke generic ACPICA GAR API - acpi_read()/acpi_write() directly.
> https://github.com/acpica/acpica/pull/209

Hi Lv,

I'm a bit confuse about the commit you said, do you mean this commit can also 
fix
this common 16-bit access width error, and will check-in to upstream kernel 
latter?
If so, please ignore this review.

Thanks,
Liwei.


> 
> Thanks and best regards
> Lv
> 
> 
> 

Re: [PATCH] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

[Liwei Song]

On 07/21/2017 05:56 PM, Andy Shevchenko wrote:
> On Fri, Jul 21, 2017 at 12:41 PM, Song liwei  wrote:
> 
>> [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]
>>
>> This is due to an 8-bit access width is specified for a 16-bit register,
>> Do bit_width check just like what the original commit have done.
> 
>> else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 
>> &&
>> *access_bit_width < 64)
>> *access_bit_width = 64;
>> +   else if (bit_width == 16 && bit_offset == 0 && (*paddr & 0x01) == 0 
>> &&
>> +   *access_bit_width < 16)
>> +   *access_bit_width = 16;
> 
> Wouldn't be better to rearrange that it will go in a sequence
> (16,32,64 or 64,32,16) ?
> 
> or move bit_offset == 0 into external condion
> 
> /* Fixup common BIOS bug */
> if (bit_offset == 0) {
>   if (bit_width == 16 && (*paddr & 0x01) == 0 && *access_bit_width < 16)
>*access_bit_width = 16;
>   else if (bit_width == 32 && (*paddr & 0x03) == 0 &&
> *access_bit_width < 32)
>*access_bit_width = 32;
>   else if (bit_width == 64 && (*paddr & 0x07) == 0 &&
> *access_bit_width < 64)
>*access_bit_width = 64;
> }
> 
> 
> It might be (I'm not sure it will make it better, just a side note)
> considered to convert each internal conditional to
> 
> ...if (bit_width == XX && (*paddr & YY) == 0)
>*access_bit_width = max(*access_bit_width, bit_width);

Hi Andy,

Thanks for your suggestion, what about the condition like the following?
The main bug in bios is bit_width is not comfortable with access_bit_width
So check it first.

if (*access_bit_width < bit_width && bit_offset == 0) {
if ((bit_width == 16 && (*paddr & 0x01) == 0) ||
(bit_width == 32 && (*paddr & 0x03) == 0) ||
(bit_width == 64 && (*paddr & 0x07) == 0))
*access_bit_width = bit_width;
}


Thanks,
Liwei.


> 

Re: [PATCH] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

[Liwei Song]

On 07/21/2017 05:56 PM, Andy Shevchenko wrote:
> On Fri, Jul 21, 2017 at 12:41 PM, Song liwei  wrote:
> 
>> [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]
>>
>> This is due to an 8-bit access width is specified for a 16-bit register,
>> Do bit_width check just like what the original commit have done.
> 
>> else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 
>> &&
>> *access_bit_width < 64)
>> *access_bit_width = 64;
>> +   else if (bit_width == 16 && bit_offset == 0 && (*paddr & 0x01) == 0 
>> &&
>> +   *access_bit_width < 16)
>> +   *access_bit_width = 16;
> 
> Wouldn't be better to rearrange that it will go in a sequence
> (16,32,64 or 64,32,16) ?
> 
> or move bit_offset == 0 into external condion
> 
> /* Fixup common BIOS bug */
> if (bit_offset == 0) {
>   if (bit_width == 16 && (*paddr & 0x01) == 0 && *access_bit_width < 16)
>*access_bit_width = 16;
>   else if (bit_width == 32 && (*paddr & 0x03) == 0 &&
> *access_bit_width < 32)
>*access_bit_width = 32;
>   else if (bit_width == 64 && (*paddr & 0x07) == 0 &&
> *access_bit_width < 64)
>*access_bit_width = 64;
> }
> 
> 
> It might be (I'm not sure it will make it better, just a side note)
> considered to convert each internal conditional to
> 
> ...if (bit_width == XX && (*paddr & YY) == 0)
>*access_bit_width = max(*access_bit_width, bit_width);

Hi Andy,

Thanks for your suggestion, what about the condition like the following?
The main bug in bios is bit_width is not comfortable with access_bit_width
So check it first.

if (*access_bit_width < bit_width && bit_offset == 0) {
if ((bit_width == 16 && (*paddr & 0x01) == 0) ||
(bit_width == 32 && (*paddr & 0x03) == 0) ||
(bit_width == 64 && (*paddr & 0x07) == 0))
*access_bit_width = bit_width;
}


Thanks,
Liwei.


> 

[PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

[Liwei Song]

Fix the following CallTrace:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 71 PID: 1 Comm: swapper/0 Not tainted 4.8.8-WR9.0.0.1_standard #11
Hardware name: Intel Corporation S2600WTT/S2600WTT,
BIOS GRNDSDP1.86B.0036.R05.1407140519 07/14/2014
 00200086 00200086 eb5e1ab8 c144dd70   eb5e1af8 c10af89a
 c1d23de4 eb5e1af8 0009 eb5d8600 eb5d8638 eb5e1af8 c10b14d8 0009
 000a c1d32911   e44c826c eb5d8000 eb5e1b74 c10b214e
Call Trace:
 [] dump_stack+0x5f/0x8f
 [] register_lock_class+0x25a/0x4c0
 [] ? check_irq_usage+0x88/0xc0
 [] __lock_acquire+0x5e/0x17a0
 [] ? _raw_spin_unlock_irqrestore+0x3b/0x70
 [] ? rcu_read_lock_sched_held+0x8a/0x90
 [] lock_acquire+0x9f/0x1f0
 [] ? dev_get_stats+0x5f/0x110
 [] ixgbe_get_stats64+0x113/0x320
 [] ? dev_get_stats+0x5f/0x110
 [] dev_get_stats+0x5f/0x110
 [] rtnl_fill_stats+0x40/0x105
 [] rtnl_fill_ifinfo+0x4c5/0xd20
 [] ? __kmalloc_node_track_caller+0x1a5/0x410
 [] ? __kmalloc_reserve.isra.42+0x27/0x80
 [] ? __alloc_skb+0x6f/0x270
 [] rtmsg_ifinfo_build_skb+0x71/0xd0
 [] rtmsg_ifinfo.part.23+0x1a/0x50
 [] ? call_netdevice_notifiers_info+0x2d/0x60
 [] rtmsg_ifinfo+0x2b/0x40
 [] register_netdevice+0x3d7/0x4d0
 [] register_netdev+0x17/0x30
 [] ixgbe_probe+0x118d/0x1610
 [] local_pci_probe+0x32/0x80
 [] ? pci_match_device+0xd2/0x100
 [] pci_device_probe+0xc0/0x110
 [] driver_probe_device+0x1c5/0x280
 [] ? pci_match_device+0xd2/0x100
 [] __driver_attach+0x89/0x90
 [] ? driver_probe_device+0x280/0x280
 [] bus_for_each_dev+0x4f/0x80
 [] driver_attach+0x1e/0x20
 [] ? driver_probe_device+0x280/0x280
 [] bus_add_driver+0x1a7/0x220
 [] driver_register+0x59/0xe0
 [] ? igb_init_module+0x49/0x49
 [] __pci_register_driver+0x4a/0x50
 [] ixgbe_init_module+0xa5/0xc4
 [] do_one_initcall+0x35/0x150
 [] ? parameq+0x18/0x70
 [] ? repair_env_string+0x12/0x51
 [] ? parse_args+0x260/0x3b0
 [] ? __usermodehelper_set_disable_depth+0x43/0x50
 [] kernel_init_freeable+0x19b/0x267
 [] ? set_debug_rodata+0xf/0xf
 [] ? trace_hardirqs_on+0xb/0x10
 [] ? _raw_spin_unlock_irq+0x32/0x50
 [] ? finish_task_switch+0xab/0x1f0
 [] ? finish_task_switch+0x69/0x1f0
 [] kernel_init+0x10/0x110
 [] ? schedule_tail+0x25/0x80
 [] ret_from_kernel_thread+0xe/0x24
 [] ? rest_init+0x130/0x130

This CallTrace occurred on 32-bit kernel with CONFIG_PROVE_LOCKING
enabled.

This happens at ixgbe driver probe hardware stage, when comes to
ixgbe_get_stats64, the seqcount/seqlock still not initialize, although
this was initialize in TX/RX resources setup routin, but it was too late,
then lockdep give this Warning.

To fix this, move the u64_stats_init function to driver probe stage,
which before we get the status of seqcount and after the RX/TX ring
was finished init.

Signed-off-by: Liwei Song <liwei.s...@windriver.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index fee1f29..ab1d114 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -5811,8 +5811,6 @@ int ixgbe_setup_tx_resources(struct ixgbe_ring *tx_ring)
if (!tx_ring->tx_buffer_info)
goto err;
 
-   u64_stats_init(_ring->syncp);
-
/* round up to nearest 4K */
tx_ring->size = tx_ring->count * sizeof(union ixgbe_adv_tx_desc);
tx_ring->size = ALIGN(tx_ring->size, 4096);
@@ -5895,8 +5893,6 @@ int ixgbe_setup_rx_resources(struct ixgbe_ring *rx_ring)
if (!rx_ring->rx_buffer_info)
goto err;
 
-   u64_stats_init(_ring->syncp);
-
/* Round up to nearest 4K */
rx_ring->size = rx_ring->count * sizeof(union ixgbe_adv_rx_desc);
rx_ring->size = ALIGN(rx_ring->size, 4096);
@@ -9686,6 +9682,12 @@ static int ixgbe_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
if (err)
goto err_sw_init;
 
+   for (i = 0; i < adapter->num_rx_queues; i++)
+   u64_stats_init(>rx_ring[i]->syncp);
+
+   for (i = 0; i < adapter->num_tx_queues; i++)
+   u64_stats_init(>tx_ring[i]->syncp);
+
/* WOL not supported for all devices */
adapter->wol = 0;
hw->eeprom.ops.read(hw, 0x2c, >eeprom_cap);
-- 
2.7.4

[PATCH] ixgbe: initialize u64_stats_sync structures early at ixgbe_probe

[Liwei Song]

Fix the following CallTrace:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 71 PID: 1 Comm: swapper/0 Not tainted 4.8.8-WR9.0.0.1_standard #11
Hardware name: Intel Corporation S2600WTT/S2600WTT,
BIOS GRNDSDP1.86B.0036.R05.1407140519 07/14/2014
 00200086 00200086 eb5e1ab8 c144dd70   eb5e1af8 c10af89a
 c1d23de4 eb5e1af8 0009 eb5d8600 eb5d8638 eb5e1af8 c10b14d8 0009
 000a c1d32911   e44c826c eb5d8000 eb5e1b74 c10b214e
Call Trace:
 [] dump_stack+0x5f/0x8f
 [] register_lock_class+0x25a/0x4c0
 [] ? check_irq_usage+0x88/0xc0
 [] __lock_acquire+0x5e/0x17a0
 [] ? _raw_spin_unlock_irqrestore+0x3b/0x70
 [] ? rcu_read_lock_sched_held+0x8a/0x90
 [] lock_acquire+0x9f/0x1f0
 [] ? dev_get_stats+0x5f/0x110
 [] ixgbe_get_stats64+0x113/0x320
 [] ? dev_get_stats+0x5f/0x110
 [] dev_get_stats+0x5f/0x110
 [] rtnl_fill_stats+0x40/0x105
 [] rtnl_fill_ifinfo+0x4c5/0xd20
 [] ? __kmalloc_node_track_caller+0x1a5/0x410
 [] ? __kmalloc_reserve.isra.42+0x27/0x80
 [] ? __alloc_skb+0x6f/0x270
 [] rtmsg_ifinfo_build_skb+0x71/0xd0
 [] rtmsg_ifinfo.part.23+0x1a/0x50
 [] ? call_netdevice_notifiers_info+0x2d/0x60
 [] rtmsg_ifinfo+0x2b/0x40
 [] register_netdevice+0x3d7/0x4d0
 [] register_netdev+0x17/0x30
 [] ixgbe_probe+0x118d/0x1610
 [] local_pci_probe+0x32/0x80
 [] ? pci_match_device+0xd2/0x100
 [] pci_device_probe+0xc0/0x110
 [] driver_probe_device+0x1c5/0x280
 [] ? pci_match_device+0xd2/0x100
 [] __driver_attach+0x89/0x90
 [] ? driver_probe_device+0x280/0x280
 [] bus_for_each_dev+0x4f/0x80
 [] driver_attach+0x1e/0x20
 [] ? driver_probe_device+0x280/0x280
 [] bus_add_driver+0x1a7/0x220
 [] driver_register+0x59/0xe0
 [] ? igb_init_module+0x49/0x49
 [] __pci_register_driver+0x4a/0x50
 [] ixgbe_init_module+0xa5/0xc4
 [] do_one_initcall+0x35/0x150
 [] ? parameq+0x18/0x70
 [] ? repair_env_string+0x12/0x51
 [] ? parse_args+0x260/0x3b0
 [] ? __usermodehelper_set_disable_depth+0x43/0x50
 [] kernel_init_freeable+0x19b/0x267
 [] ? set_debug_rodata+0xf/0xf
 [] ? trace_hardirqs_on+0xb/0x10
 [] ? _raw_spin_unlock_irq+0x32/0x50
 [] ? finish_task_switch+0xab/0x1f0
 [] ? finish_task_switch+0x69/0x1f0
 [] kernel_init+0x10/0x110
 [] ? schedule_tail+0x25/0x80
 [] ret_from_kernel_thread+0xe/0x24
 [] ? rest_init+0x130/0x130

This CallTrace occurred on 32-bit kernel with CONFIG_PROVE_LOCKING
enabled.

This happens at ixgbe driver probe hardware stage, when comes to
ixgbe_get_stats64, the seqcount/seqlock still not initialize, although
this was initialize in TX/RX resources setup routin, but it was too late,
then lockdep give this Warning.

To fix this, move the u64_stats_init function to driver probe stage,
which before we get the status of seqcount and after the RX/TX ring
was finished init.

Signed-off-by: Liwei Song 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index fee1f29..ab1d114 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -5811,8 +5811,6 @@ int ixgbe_setup_tx_resources(struct ixgbe_ring *tx_ring)
if (!tx_ring->tx_buffer_info)
goto err;
 
-   u64_stats_init(_ring->syncp);
-
/* round up to nearest 4K */
tx_ring->size = tx_ring->count * sizeof(union ixgbe_adv_tx_desc);
tx_ring->size = ALIGN(tx_ring->size, 4096);
@@ -5895,8 +5893,6 @@ int ixgbe_setup_rx_resources(struct ixgbe_ring *rx_ring)
if (!rx_ring->rx_buffer_info)
goto err;
 
-   u64_stats_init(_ring->syncp);
-
/* Round up to nearest 4K */
rx_ring->size = rx_ring->count * sizeof(union ixgbe_adv_rx_desc);
rx_ring->size = ALIGN(rx_ring->size, 4096);
@@ -9686,6 +9682,12 @@ static int ixgbe_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
if (err)
goto err_sw_init;
 
+   for (i = 0; i < adapter->num_rx_queues; i++)
+   u64_stats_init(>rx_ring[i]->syncp);
+
+   for (i = 0; i < adapter->num_tx_queues; i++)
+   u64_stats_init(>tx_ring[i]->syncp);
+
/* WOL not supported for all devices */
adapter->wol = 0;
hw->eeprom.ops.read(hw, 0x2c, >eeprom_cap);
-- 
2.7.4