in function iommu_support_dev_iotlb(),return value of device_to_iommu()
is used without checking, this could cause NULL pointer issue.
this patch is for v3.12.6
Signed-off-by: Ethan Zhao
---
drivers/iommu/intel-iommu.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
in function iommu_support_dev_iotlb(),return value of device_to_iommu()
is used without checking, this could cause NULL pointer issue.
this patch is for v3.12.6
Signed-off-by: Ethan Zhao ethan.z...@oracle.com
---
drivers/iommu/intel-iommu.c |2 ++
1 files changed, 2 insertions(+), 0
function alt_xfer() may return NULL, should check its return value passed into
create_urbs() as parameter.
gspca_init_transfer()
{
... ...
ret = create_urbs(gspca_dev,alt_xfer(>altsetting[alt], xfer));
... ...
}
Signed-off-by: Ethan Zhao
---
drivers/media/usb/gspca/gspca.c | 2 ++
1 f
Has kmalloc() failure checking there, so it is unnecessary to allocate with
__GFP_NOFAIL flag that might block forever.
Signed-off-by: Ethan Zhao
---
arch/sparc/kernel/mdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel
Has kmalloc() failure checking there, so it is unnecessary to allocate with
__GFP_NOFAIL flag that might block forever.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
arch/sparc/kernel/mdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/mdesc.c b
function alt_xfer() may return NULL, should check its return value passed into
create_urbs() as parameter.
gspca_init_transfer()
{
... ...
ret = create_urbs(gspca_dev,alt_xfer(intf-altsetting[alt], xfer));
... ...
}
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/media/usb/gspca
cc sparcli...@vger.kernel.org
On Wed, Dec 11, 2013 at 10:54 PM, Ethan Zhao wrote:
> Has kmalloc() failure checking there, so it is unnecessary to allocate with
> __GFP_NOFAIL flag that might block forever.
>
> Signed-off-by: Ethan Zhao
> ---
> arch/sparc/kernel/mdesc.c | 2 +-
David,
Got it. thanks,
Ethan
On Sun, Jan 5, 2014 at 10:05 AM, David Miller wrote:
> From: Ethan Zhao
> Date: Wed, 11 Dec 2013 22:54:21 +0800
>
>> Has kmalloc() failure checking there, so it is unnecessary to allocate with
>> __GFP_NOFAIL flag that might block fore
cx18_i2c_register() is called in cx18_init_subdevs() with index
greater than length of hw_bus array, that will cause array overrun,
introduce a helper cx18_get_max_bus_num() to avoid it.
V2: fix a typo and use ARRAY_SIZE macro
Signed-off-by: Ethan Zhao
---
drivers/media/pci/cx18/cx18-driver.c
Function saa7146_format_by_fourcc() may return NULL, reference of the returned
result would cause NULL pointer issue without checking.
Signed-off-by: Ethan Zhao
---
drivers/media/common/saa7146/saa7146_hlp.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff
Function saa7146_format_by_fourcc() may return NULL, reference of the returned
result would cause NULL pointer issue without checking.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/media/common/saa7146/saa7146_hlp.c | 22 +++---
1 file changed, 19 insertions(+), 3
cx18_i2c_register() is called in cx18_init_subdevs() with index
greater than length of hw_bus array, that will cause array overrun,
introduce a helper cx18_get_max_bus_num() to avoid it.
V2: fix a typo and use ARRAY_SIZE macro
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/media
David,
Got it. thanks,
Ethan
On Sun, Jan 5, 2014 at 10:05 AM, David Miller da...@davemloft.net wrote:
From: Ethan Zhao ethan.ker...@gmail.com
Date: Wed, 11 Dec 2013 22:54:21 +0800
Has kmalloc() failure checking there, so it is unnecessary to allocate with
__GFP_NOFAIL flag that might
cc sparcli...@vger.kernel.org
On Wed, Dec 11, 2013 at 10:54 PM, Ethan Zhao ethan.ker...@gmail.com wrote:
Has kmalloc() failure checking there, so it is unnecessary to allocate with
__GFP_NOFAIL flag that might block forever.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
arch/sparc
On Sun, Jan 5, 2014 at 2:09 PM, Dmitry Torokhov
wrote:
> Hi Ethan,
>
> On Sun, Jan 05, 2014 at 09:17:39AM +0800, Ethan Zhao wrote:
>> cx18_i2c_register() is called in cx18_init_subdevs() with index
>> greater than length of hw_bus array, that will cause array overrun,
014 at 10:08:00AM +0800, Ethan Zhao wrote:
>> Function saa7146_format_by_fourcc() may return NULL, reference of the
>> returned
>> result would cause NULL pointer issue without checking.
>>
>> Signed-off-by: Ethan Zhao
>> ---
>> drivers/media/common/saa7146/s
:
On Sun, Jan 05, 2014 at 10:08:00AM +0800, Ethan Zhao wrote:
Function saa7146_format_by_fourcc() may return NULL, reference of the
returned
result would cause NULL pointer issue without checking.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/media/common/saa7146/saa7146_hlp.c
On Sun, Jan 5, 2014 at 2:09 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
Hi Ethan,
On Sun, Jan 05, 2014 at 09:17:39AM +0800, Ethan Zhao wrote:
cx18_i2c_register() is called in cx18_init_subdevs() with index
greater than length of hw_bus array, that will cause array overrun,
introduce
Function saa7146_format_by_fourcc() may return NULL, reference of the returned
result would cause NULL pointer issue without checking.
Signed-off-by: Ethan Zhao
---
drivers/media/common/saa7146/saa7146_hlp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers
cx18_i2c_register() is called in cx18_init_subdevs() with index
greater than length of hw_bus array, that will cause array overrun,
introduce a helper cx18_get_max_bus_num() to void it.
Signed-off-by: Ethan Zhao
---
drivers/media/pci/cx18/cx18-driver.c | 2 +-
drivers/media/pci/cx18/cx18-i2c.c
cx18_i2c_register() is called in cx18_init_subdevs() with index
greater than length of hw_bus array, that will cause array overrun,
introduce a helper cx18_get_max_bus_num() to void it.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/media/pci/cx18/cx18-driver.c | 2 +-
drivers
Function saa7146_format_by_fourcc() may return NULL, reference of the returned
result would cause NULL pointer issue without checking.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/media/common/saa7146/saa7146_hlp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions
ghes_proc() always return 0 even failed to read estatus, so when it is
called in interrupt handler ghes_irq_func(), we don't know the interrupt
was handled well or not, because the ghes_irq_func() will return only
IRQ_HANDLED.
Signed-off-by: Ethan Zhao
---
drivers/acpi/apei/ghes.c | 4 ++--
1
ghes_proc() always return 0 even failed to read estatus, so when it is
called in interrupt handler ghes_irq_func(), we don't know the interrupt
was handled well or not, because the ghes_irq_func() will return only
IRQ_HANDLED.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/acpi
Because ixgbe driver limit the max number of VF functions could be enabled
to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63
in code.
v2: fix a typo.
Signed-off-by: Ethan Zhao
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
drivers/net/ethernet/intel
_set_totalvfs() before
enable VFs with ixgbe_enable_sriov().
Signed-off-by: Ethan Zhao
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
Because ixgbe driver limit the max number of VF functions could be enalbed
to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63
in code.
Signed-off-by: Ethan Zhao
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
Because ixgbe driver limit the max number of VF functions could be enalbed
to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63
in code.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
drivers/net/ethernet/intel
() before
enable VFs with ixgbe_enable_sriov().
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe
Because ixgbe driver limit the max number of VF functions could be enabled
to 63, so define one macro IXGBE_MAX_VFS_DRV_LIMIT and cleanup the const 63
in code.
v2: fix a typo.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++--
drivers
' to all the buggy CPU, is that right ?
Thanks,
Ethan
On Mon, Oct 7, 2013 at 12:57 PM, Ethan Zhao wrote:
> Got it.
>
> On Mon, Oct 7, 2013 at 12:41 PM, Mike Galbraith wrote:
>> On Fri, 2013-10-04 at 20:06 +0800, Ethan Zhao wrote:
>>> Mike, Peter,
>>>
' to all the buggy CPU, is that right ?
Thanks,
Ethan
On Mon, Oct 7, 2013 at 12:57 PM, Ethan Zhao ethan.ker...@gmail.com wrote:
Got it.
On Mon, Oct 7, 2013 at 12:41 PM, Mike Galbraith bitbuc...@online.de wrote:
On Fri, 2013-10-04 at 20:06 +0800, Ethan Zhao wrote:
Mike, Peter,
Seems
.
Signed-off-by: Ethan Zhao
---
drivers/infiniband/hw/cxgb4/mem.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 19 ++-
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/mem.c
b/drivers/infiniband/hw/cxgb4/mem.c
Has kmalloc() failure checking there, so it is unnecessary to allocate with
__GFP_NOFAIL flag that might block forever.
Signed-off-by: Ethan Zhao
---
arch/sparc/kernel/mdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel
Has kmalloc() failure checking there, so it is unnecessary to allocate with
__GFP_NOFAIL flag that might block forever.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
arch/sparc/kernel/mdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/mdesc.c b
.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/infiniband/hw/cxgb4/mem.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 19 ++-
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/mem.c
b/drivers
On Tue, Dec 10, 2013 at 10:11 PM, Konrad Rzeszutek Wilk
wrote:
> Ethan Zhao wrote:
>>Konrad,
>>
>> boot_kset was allocated when module loaded by
>>ibft_init()
>> iscsi_boot_create_kset()
>> kzalloc()
>>
>>but wasn't freed when
On Tue, Dec 10, 2013 at 4:19 PM, Greg KH wrote:
> On Tue, Dec 10, 2013 at 04:03:41PM +0800, Ethan Zhao wrote:
>> On Tue, Dec 10, 2013 at 2:40 AM, Greg KH wrote:
>> > On Mon, Dec 09, 2013 at 09:42:23PM +0800, Ethan Zhao wrote:
>> >> Greg,
>> >> I am
Christoph,
No, stable 3.12.4 and 3.12.3 need this patch. 3.13RC doesn't
need it anymore.
Thanks,
Ethan
On Tue, Dec 10, 2013 at 3:08 PM, Ethan Zhao wrote:
> Christoph,
> Found in the latest stable release V3.12.3, yes, changed in
> 3.12.4. not needed for later releas
On Tue, Dec 10, 2013 at 2:40 AM, Greg KH wrote:
> On Mon, Dec 09, 2013 at 09:42:23PM +0800, Ethan Zhao wrote:
>> Greg,
>> I am the man who built a Xen dom0, but couldn't see debugfs
>> directory and files as expected. there is no warning or tip for me to
>> e
On Tue, Dec 10, 2013 at 4:19 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, Dec 10, 2013 at 04:03:41PM +0800, Ethan Zhao wrote:
On Tue, Dec 10, 2013 at 2:40 AM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Dec 09, 2013 at 09:42:23PM +0800, Ethan Zhao wrote:
Greg,
I am
On Tue, Dec 10, 2013 at 10:11 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
Ethan Zhao ethan.ker...@gmail.com wrote:
Konrad,
boot_kset was allocated when module loaded by
ibft_init()
iscsi_boot_create_kset()
kzalloc()
but wasn't freed when module unloaded by
ibft_exit
On Tue, Dec 10, 2013 at 2:40 AM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Dec 09, 2013 at 09:42:23PM +0800, Ethan Zhao wrote:
Greg,
I am the man who built a Xen dom0, but couldn't see debugfs
directory and files as expected. there is no warning or tip for me to
enable
Christoph,
No, stable 3.12.4 and 3.12.3 need this patch. 3.13RC doesn't
need it anymore.
Thanks,
Ethan
On Tue, Dec 10, 2013 at 3:08 PM, Ethan Zhao ethan.ker...@gmail.com wrote:
Christoph,
Found in the latest stable release V3.12.3, yes, changed in
3.12.4. not needed for later
On Tue, Dec 10, 2013 at 3:08 AM, Greg Kroah-Hartman
wrote:
> On Mon, Dec 09, 2013 at 11:24:04PM +0800, Ethan Zhao wrote:
>> On Sun, Dec 8, 2013 at 11:50 AM, Greg Kroah-Hartman
>> wrote:
>> > On Sat, Dec 07, 2013 at 07:31:21PM -0800, Yinghai Lu wrote:
>> >>
Christoph,
Found in the latest stable release V3.12.3, yes, changed in
3.12.4. not needed for later release anymore.
Thanks,
Ethan
On Tue, Dec 10, 2013 at 12:11 AM, Christoph Lameter wrote:
> On Sun, 8 Dec 2013, ethan.zhao wrote:
>
>> Move the NULL check of slabp to the right place before
Laurent,
Next time I scan the NULL check, if hit your driver again, I will resend it.
Thanks,
Ethan
On Tue, Dec 10, 2013 at 10:24 AM, Laurent Pinchart
wrote:
> Hi Ethan,
>
> Thank you for the patch.
>
> On Sunday 08 December 2013 10:41:46 ethan.zhao wrote:
>> function
:
> On Mon, Dec 09, 2013 at 05:37:11PM +0800, Ethan Zhao wrote:
>> From: "Ethan Zhao"
>>
>> Load and unload iscsi_ibft module will cause kernel memory leak, fix it
>> in scsi/iscsi_boot_sysfs.c iscsi_boot_destroy_kset().
>>
>
> Is there a stack trace?
>
On Sun, Dec 8, 2013 at 11:50 AM, Greg Kroah-Hartman
wrote:
> On Sat, Dec 07, 2013 at 07:31:21PM -0800, Yinghai Lu wrote:
>> [+ GregKH]
>>
>> On Fri, Dec 6, 2013 at 5:27 PM, Rafael J. Wysocki wrote:
>> > On Thursday, December 05, 2013 10:52:36 PM Yinghai Lu wrote:
>> >> On Mon, Dec 2, 2013 at
On Mon, Dec 9, 2013 at 7:19 PM, Greg KH wrote:
> On Mon, Dec 09, 2013 at 05:56:52PM +0800, Ethan Zhao wrote:
>> From: "ethan.zhao"
>>
>> Should check debugfs initialization with debugfs_initialized() before using
>> it,
>> Because if it
as
zswap_debugfs, tracer_debugfs ,rproc_debugfs did. Is it useless ? if
it could save me just 1 minute next time ?
Thanks,
Ethan
On Mon, Dec 9, 2013 at 7:17 PM, Greg KH wrote:
> On Mon, Dec 09, 2013 at 05:57:22PM +0800, Ethan Zhao wrote:
>> On Mon, Dec 9, 2013 at 4:55 PM, Greg KH wrote:
&g
message about debugfs not configured or disabled.
V4: make the warning clear.
Signed-off-by: Ethan Zhao
---
arch/x86/xen/debugfs.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
index c8377fb..7f3804c 100644
--- a/arch/x86/xen/debugfs.c
From: "Ethan Zhao"
Should check debugfs initialization with debugfs_initialized() before using it,
Because if it isn't initialized, the return value of fake debugfs_create_dir()
etc
functions would be ERR_PTR(-ENODEV), checking with NULL will not work.
V3: Add warning message abo
Greg,
How about the V3 ?
Thanks,
Ethan
On Mon, Dec 9, 2013 at 5:56 PM, Ethan Zhao wrote:
> From: "ethan.zhao"
>
> Should check debugfs initialization with debugfs_initialized() before using
> it,
> Because if it isn't initialized, the return value of fake
&
All,
Please ignore this one, sorry, see v3.
Thanks,
Ethan
On Mon, Dec 9, 2013 at 5:42 PM, Ethan Zhao wrote:
> From: "Ethan Zhao"
>
> Should check debugfs initialization with debugfs_initialized() before using
> it,
> Because if it isn't initialized,
From: "ethan.zhao"
Should check debugfs initialization with debugfs_initialized() before using it,
Because if it isn't initialized, the return value of fake debugfs_create_dir()
etc
functions would be ERR_PTR(-ENODEV), checking with NULL will not work.
V3: add warning message when debugfs not
On Mon, Dec 9, 2013 at 4:55 PM, Greg KH wrote:
> On Mon, Dec 09, 2013 at 04:44:05PM +0800, Ethan Zhao wrote:
>> On Mon, Dec 9, 2013 at 4:25 PM, Greg KH wrote:
>> > On Mon, Dec 09, 2013 at 09:43:16AM +0800, Ethan Zhao wrote:
>> >> On Sun, Dec 8, 2013 at 1
From: "Ethan Zhao"
Should check debugfs initialization with debugfs_initialized() before using it,
Because if it isn't initialized, the return value of fake debugfs_create_dir()
etc
functions would be ERR_PTR(-ENODEV), checking with NULL will not work.
V2: change to normative a
From: "Ethan Zhao"
Load and unload iscsi_ibft module will cause kernel memory leak, fix it
in scsi/iscsi_boot_sysfs.c iscsi_boot_destroy_kset().
Signed-off-by: Ethan Zhao
---
drivers/scsi/iscsi_boot_sysfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/iscsi_boot
On Mon, Dec 9, 2013 at 4:25 PM, Greg KH wrote:
> On Mon, Dec 09, 2013 at 09:43:16AM +0800, Ethan Zhao wrote:
>> On Sun, Dec 8, 2013 at 10:01 PM, Greg KH wrote:
>> > On Sun, Dec 08, 2013 at 07:31:02PM +0800, ethan.zhao wrote:
>> >> Should check debugfs initializ
On Mon, Dec 9, 2013 at 4:25 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Dec 09, 2013 at 09:43:16AM +0800, Ethan Zhao wrote:
On Sun, Dec 8, 2013 at 10:01 PM, Greg KH gre...@linuxfoundation.org wrote:
On Sun, Dec 08, 2013 at 07:31:02PM +0800, ethan.zhao wrote:
Should check debugfs
From: Ethan Zhao ethan.ker...@gmail.com
Load and unload iscsi_ibft module will cause kernel memory leak, fix it
in scsi/iscsi_boot_sysfs.c iscsi_boot_destroy_kset().
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
drivers/scsi/iscsi_boot_sysfs.c | 1 +
1 file changed, 1 insertion(+)
diff
From: Ethan Zhao ethan.ker...@gmail.com
Should check debugfs initialization with debugfs_initialized() before using it,
Because if it isn't initialized, the return value of fake debugfs_create_dir()
etc
functions would be ERR_PTR(-ENODEV), checking with NULL will not work.
V2: change
On Mon, Dec 9, 2013 at 4:55 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Dec 09, 2013 at 04:44:05PM +0800, Ethan Zhao wrote:
On Mon, Dec 9, 2013 at 4:25 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Dec 09, 2013 at 09:43:16AM +0800, Ethan Zhao wrote:
On Sun, Dec 8, 2013
From: ethan.zhao ethan.ker...@gmail.com
Should check debugfs initialization with debugfs_initialized() before using it,
Because if it isn't initialized, the return value of fake debugfs_create_dir()
etc
functions would be ERR_PTR(-ENODEV), checking with NULL will not work.
V3: add warning
All,
Please ignore this one, sorry, see v3.
Thanks,
Ethan
On Mon, Dec 9, 2013 at 5:42 PM, Ethan Zhao ethan.ker...@gmail.com wrote:
From: Ethan Zhao ethan.ker...@gmail.com
Should check debugfs initialization with debugfs_initialized() before using
it,
Because if it isn't initialized
Greg,
How about the V3 ?
Thanks,
Ethan
On Mon, Dec 9, 2013 at 5:56 PM, Ethan Zhao ethan.ker...@gmail.com wrote:
From: ethan.zhao ethan.ker...@gmail.com
Should check debugfs initialization with debugfs_initialized() before using
it,
Because if it isn't initialized, the return value
From: Ethan Zhao ethan.ker...@gmail.com
Should check debugfs initialization with debugfs_initialized() before using it,
Because if it isn't initialized, the return value of fake debugfs_create_dir()
etc
functions would be ERR_PTR(-ENODEV), checking with NULL will not work.
V3: Add warning
message about debugfs not configured or disabled.
V4: make the warning clear.
Signed-off-by: Ethan Zhao ethan.ker...@gmail.com
---
arch/x86/xen/debugfs.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/xen/debugfs.c b/arch/x86/xen/debugfs.c
index c8377fb..7f3804c 100644
as
zswap_debugfs, tracer_debugfs ,rproc_debugfs did. Is it useless ? if
it could save me just 1 minute next time ?
Thanks,
Ethan
On Mon, Dec 9, 2013 at 7:17 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Dec 09, 2013 at 05:57:22PM +0800, Ethan Zhao wrote:
On Mon, Dec 9, 2013 at 4:55 PM, Greg KH
On Mon, Dec 9, 2013 at 7:19 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Dec 09, 2013 at 05:56:52PM +0800, Ethan Zhao wrote:
From: ethan.zhao ethan.ker...@gmail.com
Should check debugfs initialization with debugfs_initialized() before using
it,
Because if it isn't initialized
On Sun, Dec 8, 2013 at 11:50 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Sat, Dec 07, 2013 at 07:31:21PM -0800, Yinghai Lu wrote:
[+ GregKH]
On Fri, Dec 6, 2013 at 5:27 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, December 05, 2013 10:52:36 PM Yinghai Lu
...@oracle.com wrote:
On Mon, Dec 09, 2013 at 05:37:11PM +0800, Ethan Zhao wrote:
From: Ethan Zhao ethan.ker...@gmail.com
Load and unload iscsi_ibft module will cause kernel memory leak, fix it
in scsi/iscsi_boot_sysfs.c iscsi_boot_destroy_kset().
Is there a stack trace?
Signed-off-by: Ethan Zhao
Laurent,
Next time I scan the NULL check, if hit your driver again, I will resend it.
Thanks,
Ethan
On Tue, Dec 10, 2013 at 10:24 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Ethan,
Thank you for the patch.
On Sunday 08 December 2013 10:41:46 ethan.zhao wrote:
Christoph,
Found in the latest stable release V3.12.3, yes, changed in
3.12.4. not needed for later release anymore.
Thanks,
Ethan
On Tue, Dec 10, 2013 at 12:11 AM, Christoph Lameter c...@linux.com wrote:
On Sun, 8 Dec 2013, ethan.zhao wrote:
Move the NULL check of slabp to the right
On Tue, Dec 10, 2013 at 3:08 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Mon, Dec 09, 2013 at 11:24:04PM +0800, Ethan Zhao wrote:
On Sun, Dec 8, 2013 at 11:50 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Sat, Dec 07, 2013 at 07:31:21PM -0800, Yinghai Lu wrote
Nick,
You could try 7.3.21-k8-NAPI in tree or the out-of-tree version as
Bjorn mentioned.
To read and debug an old version driver is not a interesting thing for
somebody to do.
Thanks,
Ethan
On Tue, Dec 3, 2013 at 9:33 PM, Nick Pegg wrote:
> On Mon, Dec 2, 2013 at 10:51 PM, Ethan Z
On Sun, Dec 8, 2013 at 10:01 PM, Greg KH wrote:
> On Sun, Dec 08, 2013 at 07:31:02PM +0800, ethan.zhao wrote:
>> Should check debugfs initialization with debugfs_initialized() before using
>> it,
>> Because if it isn't initialized, the return value of fake
>> debugfs_create_dir() etc
>>
On Sun, Dec 8, 2013 at 10:01 PM, Greg KH gre...@linuxfoundation.org wrote:
On Sun, Dec 08, 2013 at 07:31:02PM +0800, ethan.zhao wrote:
Should check debugfs initialization with debugfs_initialized() before using
it,
Because if it isn't initialized, the return value of fake
, Ethan Zhao ethan.ker...@gmail.com wrote:
Bjorn,
Seems not the same bug as http://sourceforge.net/p/e1000/bugs/367/
, Nick is not running his kernel on bare metal, per the error log,
he runs his kernel as HVM DomU guest or Dom0 on XEN ? so just a check
of NULL will not fix that.
Sorry
Rui,
I like this patch. thanks your revision.
Ethan
On Sun, Dec 8, 2013 at 12:17 PM, Rui Wang wrote:
> There's inconsistency between dmesg and the trace event output.
> When dmesg says "severity=Corrected", the trace event says
> "severity=Fatal". What happens is that HW_EVENT_ERR_CORRECTED
Rui,
I like this patch. thanks your revision.
Ethan
On Sun, Dec 8, 2013 at 12:17 PM, Rui Wang ruiv.w...@gmail.com wrote:
There's inconsistency between dmesg and the trace event output.
When dmesg says severity=Corrected, the trace event says
severity=Fatal. What happens is that
Jiang,
Could you help to take a look such performance issue about Intel
IOMMU, seems you go back this field of Intel. Is it possible to
eliminate the performance side effect of mapping and unmapping
operation ? some context information, please refer to the first mail
of this loop.
Thanks,
On Fri, Dec 6, 2013 at 5:06 PM, rui wang wrote:
> On 12/5/13, Borislav Petkov wrote:
>
>> Yes, the AER tracepoint above should use the AER_* defines and not the
>> HW_EVENT_ERR_* ones which are for memory errors.
>>
>> Wanna send a fix?
>>
>
> Yes. Does it translate into something like this?
>
>
On Fri, Dec 6, 2013 at 5:06 PM, rui wang ruiv.w...@gmail.com wrote:
On 12/5/13, Borislav Petkov b...@alien8.de wrote:
Yes, the AER tracepoint above should use the AER_* defines and not the
HW_EVENT_ERR_* ones which are for memory errors.
Wanna send a fix?
Yes. Does it translate into
Jiang,
Could you help to take a look such performance issue about Intel
IOMMU, seems you go back this field of Intel. Is it possible to
eliminate the performance side effect of mapping and unmapping
operation ? some context information, please refer to the first mail
of this loop.
Thanks,
Rui,
Agree with that, there are really many such confusing error type definition
need to be standardized or unified, some of them are
ambiguous、inconsistent, some of them violates ACPI/PCI spec.
According to the ACPI spec, the 'FATAL' in fact, is a sub-category
of 'UNCORRECTABLE' , the
Rui,
Agree with that, there are really many such confusing error type definition
need to be standardized or unified, some of them are
ambiguous、inconsistent, some of them violates ACPI/PCI spec.
According to the ACPI spec, the 'FATAL' in fact, is a sub-category
of 'UNCORRECTABLE' , the
Bjorn,
Seems not the same bug as http://sourceforge.net/p/e1000/bugs/367/
, Nick is not running his kernel on bare metal, per the error log,
he runs his kernel as HVM DomU guest or Dom0 on XEN ? so just a check
of NULL will not fix that.
Thanks,
Ethan
On Thu, Nov 21, 2013 at 5:22 AM, Bjorn
Bjorn,
Seems not the same bug as http://sourceforge.net/p/e1000/bugs/367/
, Nick is not running his kernel on bare metal, per the error log,
he runs his kernel as HVM DomU guest or Dom0 on XEN ? so just a check
of NULL will not fix that.
Thanks,
Ethan
On Thu, Nov 21, 2013 at 5:22 AM, Bjorn
Bjorn,
I revised the description part with the original bug material as
below, help to take a look, will send V2 back to home, SMTP blocked by
company network.
PCI: Init NumVFs register to zero in sriov_init()
Though no specification about NumVFs register initial value after
POST, to
Bjorn,
To be honest, the output above is picked up from other guy's mail,
because I composed the patch mail at home and left the real bug
material at company, they 'really' hit an issue confused by lspci
output while SR-IOV is initialized to disabled .
There is an error in above output as
Bjorn,
To be honest, the output above is picked up from other guy's mail,
because I composed the patch mail at home and left the real bug
material at company, they 'really' hit an issue confused by lspci
output while SR-IOV is initialized to disabled .
There is an error in above output as
Bjorn,
I revised the description part with the original bug material as
below, help to take a look, will send V2 back to home, SMTP blocked by
company network.
PCI: Init NumVFs register to zero in sriov_init()
Though no specification about NumVFs register initial value after
POST, to
On Fri, Nov 15, 2013 at 2:59 PM, Yinghai Lu wrote:
> On Wed, Nov 13, 2013 at 5:57 PM, Ethan Zhao wrote:
>> On Wed, Nov 6, 2013 at 10:49 PM, ethan.zhao wrote:
>>> Though no specification about NumVFs register initial value after POST, to
>>> void the confusion
&g
On Fri, Nov 15, 2013 at 2:59 PM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Nov 13, 2013 at 5:57 PM, Ethan Zhao ethan.ker...@gmail.com wrote:
On Wed, Nov 6, 2013 at 10:49 PM, ethan.zhao ethan.ker...@gmail.com wrote:
Though no specification about NumVFs register initial value after POST
Yinghai,
Could you help to take a look, we need it in our downstream kernel.
Thanks,
Ethan
On Wed, Nov 6, 2013 at 10:49 PM, ethan.zhao wrote:
> Though no specification about NumVFs register initial value after POST, to
> void the confusion
> lspci output as following before VF was
Yinghai,
Could you help to take a look, we need it in our downstream kernel.
Thanks,
Ethan
On Wed, Nov 6, 2013 at 10:49 PM, ethan.zhao ethan.ker...@gmail.com wrote:
Though no specification about NumVFs register initial value after POST, to
void the confusion
lspci output as following
for last HTML mail, resend txt )
Ethan
On Tue, Nov 12, 2013 at 9:34 AM, Eric Dumazet wrote:
> On Tue, 2013-11-12 at 09:03 +0800, Ethan Zhao wrote:
>> Eric,
>> We have tested the performance with the TSO and TSQ patches
>> merged, the result not good, even worse than ker
k driver: be2net
Average Bandwidth for :
1.tcp-unidirectional test: 7992 Mbits/sec
2.tcp-unidirectional-parallel: 9403 Mbits/sec
3.tcp-bidirectonal test : 5802 Mbits/sec
Thanks,
Ethan
On Thu, Oct 31, 2013 at 11:25 PM, Eric Dumazet wrote:
> On Thu, 2013-10-31 at 10:44 +
501 - 600 of 646 matches
Mail list logo
