Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Daniel Vetter]

On Tue, Sep 12, 2017 at 06:54:45PM +0100, Emil Velikov wrote:
> On 12 September 2017 at 18:47, Colin Ian King <colin.k...@canonical.com> 
> wrote:
> > On 12/09/17 18:42, Thomas Hellstrom wrote:
> >> Hi, Colin,
> >>
> >> On 09/12/2017 07:35 PM, Colin King wrote:
> >>> From: Colin Ian King <colin.k...@canonical.com>
> >>>
> >>> mmap'ing the device multiple times will spam the kernel log with the
> >>> DRM_ERROR message about illegal mmap'ing the old fifo space.
> >> How are you hitting this? Multiple mappings should be fine as long as
> >> mapping offsets are correct,
> >> so hitting this message should indicate that the user-space app is doing
> >> something seriously wrong, and
> >> having it present in the log should probably help more than it hurts.
> >>
> >> /Thomas
> >
> > Good question.  I hit similar issues with the drm qxl driver when
> > running some kernel regression tests with stress-ng [1]. I realize this
> > is an artificial test scenario so it is definitely not a typical
> > use-case, however, sync the illegal mmapping will return -EINVAL the
> > application will pick up that this is an error without the need of
> > spotting it in the kernel log. And a user space application can perform
> > many millions of these invalid mmaps causing kernel log spamming.
> >
> FWIW I'm the one to "blame" here - pointing Colin to drop the message.
> 
> Two reasons come to mind:
>  - there is a unwritten rule that roughly says "user input should not
> cause kernel log spam"
>  - out of all the DRM drivers only QXL and VMWGFX print a message,
> with a patch addressing the former

Maybe we should make this a written rule by patching
Documentation/drivers/gpu? Would definitely make sense as part of this
patch series.

Thanks, Daniel
> 
> HTH
> Emil
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Daniel Vetter]

On Tue, Sep 12, 2017 at 06:54:45PM +0100, Emil Velikov wrote:
> On 12 September 2017 at 18:47, Colin Ian King  
> wrote:
> > On 12/09/17 18:42, Thomas Hellstrom wrote:
> >> Hi, Colin,
> >>
> >> On 09/12/2017 07:35 PM, Colin King wrote:
> >>> From: Colin Ian King 
> >>>
> >>> mmap'ing the device multiple times will spam the kernel log with the
> >>> DRM_ERROR message about illegal mmap'ing the old fifo space.
> >> How are you hitting this? Multiple mappings should be fine as long as
> >> mapping offsets are correct,
> >> so hitting this message should indicate that the user-space app is doing
> >> something seriously wrong, and
> >> having it present in the log should probably help more than it hurts.
> >>
> >> /Thomas
> >
> > Good question.  I hit similar issues with the drm qxl driver when
> > running some kernel regression tests with stress-ng [1]. I realize this
> > is an artificial test scenario so it is definitely not a typical
> > use-case, however, sync the illegal mmapping will return -EINVAL the
> > application will pick up that this is an error without the need of
> > spotting it in the kernel log. And a user space application can perform
> > many millions of these invalid mmaps causing kernel log spamming.
> >
> FWIW I'm the one to "blame" here - pointing Colin to drop the message.
> 
> Two reasons come to mind:
>  - there is a unwritten rule that roughly says "user input should not
> cause kernel log spam"
>  - out of all the DRM drivers only QXL and VMWGFX print a message,
> with a patch addressing the former

Maybe we should make this a written rule by patching
Documentation/drivers/gpu? Would definitely make sense as part of this
patch series.

Thanks, Daniel
> 
> HTH
> Emil
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Emil Velikov]

On 12 September 2017 at 18:47, Colin Ian King <colin.k...@canonical.com> wrote:
> On 12/09/17 18:42, Thomas Hellstrom wrote:
>> Hi, Colin,
>>
>> On 09/12/2017 07:35 PM, Colin King wrote:
>>> From: Colin Ian King <colin.k...@canonical.com>
>>>
>>> mmap'ing the device multiple times will spam the kernel log with the
>>> DRM_ERROR message about illegal mmap'ing the old fifo space.
>> How are you hitting this? Multiple mappings should be fine as long as
>> mapping offsets are correct,
>> so hitting this message should indicate that the user-space app is doing
>> something seriously wrong, and
>> having it present in the log should probably help more than it hurts.
>>
>> /Thomas
>
> Good question.  I hit similar issues with the drm qxl driver when
> running some kernel regression tests with stress-ng [1]. I realize this
> is an artificial test scenario so it is definitely not a typical
> use-case, however, sync the illegal mmapping will return -EINVAL the
> application will pick up that this is an error without the need of
> spotting it in the kernel log. And a user space application can perform
> many millions of these invalid mmaps causing kernel log spamming.
>
FWIW I'm the one to "blame" here - pointing Colin to drop the message.

Two reasons come to mind:
 - there is a unwritten rule that roughly says "user input should not
cause kernel log spam"
 - out of all the DRM drivers only QXL and VMWGFX print a message,
with a patch addressing the former

HTH
Emil

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Emil Velikov]

On 12 September 2017 at 18:47, Colin Ian King  wrote:
> On 12/09/17 18:42, Thomas Hellstrom wrote:
>> Hi, Colin,
>>
>> On 09/12/2017 07:35 PM, Colin King wrote:
>>> From: Colin Ian King 
>>>
>>> mmap'ing the device multiple times will spam the kernel log with the
>>> DRM_ERROR message about illegal mmap'ing the old fifo space.
>> How are you hitting this? Multiple mappings should be fine as long as
>> mapping offsets are correct,
>> so hitting this message should indicate that the user-space app is doing
>> something seriously wrong, and
>> having it present in the log should probably help more than it hurts.
>>
>> /Thomas
>
> Good question.  I hit similar issues with the drm qxl driver when
> running some kernel regression tests with stress-ng [1]. I realize this
> is an artificial test scenario so it is definitely not a typical
> use-case, however, sync the illegal mmapping will return -EINVAL the
> application will pick up that this is an error without the need of
> spotting it in the kernel log. And a user space application can perform
> many millions of these invalid mmaps causing kernel log spamming.
>
FWIW I'm the one to "blame" here - pointing Colin to drop the message.

Two reasons come to mind:
 - there is a unwritten rule that roughly says "user input should not
cause kernel log spam"
 - out of all the DRM drivers only QXL and VMWGFX print a message,
with a patch addressing the former

HTH
Emil

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Colin Ian King]

On 12/09/17 18:42, Thomas Hellstrom wrote:
> Hi, Colin,
> 
> On 09/12/2017 07:35 PM, Colin King wrote:
>> From: Colin Ian King <colin.k...@canonical.com>
>>
>> mmap'ing the device multiple times will spam the kernel log with the
>> DRM_ERROR message about illegal mmap'ing the old fifo space.
> How are you hitting this? Multiple mappings should be fine as long as
> mapping offsets are correct,
> so hitting this message should indicate that the user-space app is doing
> something seriously wrong, and
> having it present in the log should probably help more than it hurts.
> 
> /Thomas

Good question.  I hit similar issues with the drm qxl driver when
running some kernel regression tests with stress-ng [1]. I realize this
is an artificial test scenario so it is definitely not a typical
use-case, however, sync the illegal mmapping will return -EINVAL the
application will pick up that this is an error without the need of
spotting it in the kernel log. And a user space application can perform
many millions of these invalid mmaps causing kernel log spamming.

[1] http://kernel.ubuntu.com/~cking/stress-ng/

> 
> 
> 
>> Since
>> the mmap'ing will fail with an -EINVAL there is no need to emit this
>> message, so just remove it.
>>
>> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
>> ---
>>   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> index e771091d2cd3..1e633c602fb1 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> @@ -33,10 +33,8 @@ int vmw_mmap(struct file *filp, struct
>> vm_area_struct *vma)
>>   struct drm_file *file_priv;
>>   struct vmw_private *dev_priv;
>>   -if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET)) {
>> -DRM_ERROR("Illegal attempt to mmap old fifo space.\n");
>> +if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET))
>>   return -EINVAL;
>> -}
>> file_priv = filp->private_data;
>>   dev_priv = vmw_priv(file_priv->minor->dev);
> 
> 

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Colin Ian King]

On 12/09/17 18:42, Thomas Hellstrom wrote:
> Hi, Colin,
> 
> On 09/12/2017 07:35 PM, Colin King wrote:
>> From: Colin Ian King 
>>
>> mmap'ing the device multiple times will spam the kernel log with the
>> DRM_ERROR message about illegal mmap'ing the old fifo space.
> How are you hitting this? Multiple mappings should be fine as long as
> mapping offsets are correct,
> so hitting this message should indicate that the user-space app is doing
> something seriously wrong, and
> having it present in the log should probably help more than it hurts.
> 
> /Thomas

Good question.  I hit similar issues with the drm qxl driver when
running some kernel regression tests with stress-ng [1]. I realize this
is an artificial test scenario so it is definitely not a typical
use-case, however, sync the illegal mmapping will return -EINVAL the
application will pick up that this is an error without the need of
spotting it in the kernel log. And a user space application can perform
many millions of these invalid mmaps causing kernel log spamming.

[1] http://kernel.ubuntu.com/~cking/stress-ng/

> 
> 
> 
>> Since
>> the mmap'ing will fail with an -EINVAL there is no need to emit this
>> message, so just remove it.
>>
>> Signed-off-by: Colin Ian King 
>> ---
>>   drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> index e771091d2cd3..1e633c602fb1 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>> @@ -33,10 +33,8 @@ int vmw_mmap(struct file *filp, struct
>> vm_area_struct *vma)
>>   struct drm_file *file_priv;
>>   struct vmw_private *dev_priv;
>>   -if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET)) {
>> -DRM_ERROR("Illegal attempt to mmap old fifo space.\n");
>> +if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET))
>>   return -EINVAL;
>> -}
>> file_priv = filp->private_data;
>>   dev_priv = vmw_priv(file_priv->minor->dev);
> 
> 

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Thomas Hellstrom]

Hi, Colin,

On 09/12/2017 07:35 PM, Colin King wrote:

From: Colin Ian King 

mmap'ing the device multiple times will spam the kernel log with the
DRM_ERROR message about illegal mmap'ing the old fifo space.
How are you hitting this? Multiple mappings should be fine as long as 
mapping offsets are correct,
so hitting this message should indicate that the user-space app is doing 
something seriously wrong, and

having it present in the log should probably help more than it hurts.

/Thomas




Since
the mmap'ing will fail with an -EINVAL there is no need to emit this
message, so just remove it.

Signed-off-by: Colin Ian King 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index e771091d2cd3..1e633c602fb1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -33,10 +33,8 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
struct drm_file *file_priv;
struct vmw_private *dev_priv;
  
-	if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET)) {

-   DRM_ERROR("Illegal attempt to mmap old fifo space.\n");
+   if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET))
return -EINVAL;
-   }
  
  	file_priv = filp->private_data;

dev_priv = vmw_priv(file_priv->minor->dev);

Re: [PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Thomas Hellstrom]

Hi, Colin,

On 09/12/2017 07:35 PM, Colin King wrote:

From: Colin Ian King 

mmap'ing the device multiple times will spam the kernel log with the
DRM_ERROR message about illegal mmap'ing the old fifo space.
How are you hitting this? Multiple mappings should be fine as long as 
mapping offsets are correct,
so hitting this message should indicate that the user-space app is doing 
something seriously wrong, and

having it present in the log should probably help more than it hurts.

/Thomas




Since
the mmap'ing will fail with an -EINVAL there is no need to emit this
message, so just remove it.

Signed-off-by: Colin Ian King 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index e771091d2cd3..1e633c602fb1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -33,10 +33,8 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
struct drm_file *file_priv;
struct vmw_private *dev_priv;
  
-	if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET)) {

-   DRM_ERROR("Illegal attempt to mmap old fifo space.\n");
+   if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET))
return -EINVAL;
-   }
  
  	file_priv = filp->private_data;

dev_priv = vmw_priv(file_priv->minor->dev);

[PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Colin King]

From: Colin Ian King 

mmap'ing the device multiple times will spam the kernel log with the
DRM_ERROR message about illegal mmap'ing the old fifo space. Since
the mmap'ing will fail with an -EINVAL there is no need to emit this
message, so just remove it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index e771091d2cd3..1e633c602fb1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -33,10 +33,8 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
struct drm_file *file_priv;
struct vmw_private *dev_priv;
 
-   if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET)) {
-   DRM_ERROR("Illegal attempt to mmap old fifo space.\n");
+   if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET))
return -EINVAL;
-   }
 
file_priv = filp->private_data;
dev_priv = vmw_priv(file_priv->minor->dev);
-- 
2.14.1

[PATCH] drm/vmwgfx: remove DRM_ERROR message, stops log spamming

[Colin King]

From: Colin Ian King 

mmap'ing the device multiple times will spam the kernel log with the
DRM_ERROR message about illegal mmap'ing the old fifo space. Since
the mmap'ing will fail with an -EINVAL there is no need to emit this
message, so just remove it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index e771091d2cd3..1e633c602fb1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -33,10 +33,8 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
struct drm_file *file_priv;
struct vmw_private *dev_priv;
 
-   if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET)) {
-   DRM_ERROR("Illegal attempt to mmap old fifo space.\n");
+   if (unlikely(vma->vm_pgoff < VMWGFX_FILE_PAGE_OFFSET))
return -EINVAL;
-   }
 
file_priv = filp->private_data;
dev_priv = vmw_priv(file_priv->minor->dev);
-- 
2.14.1

[PATCH][V2] drm: qxl: remove pr_info message, stops log spamming

[Colin King]

From: Colin Ian King 

Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:

int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");

for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED, fd, 0);
if (m != MAP_FAILED)
munmap(m, 4096);
}
}

Stop the spamming by removing the pr_info message. Since the mmap'ing
returns -EINVAL there is no need for the pr_info message.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/qxl/qxl_ttm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 7ecf8a4b9fe6..0f50c0b25a58 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -123,11 +123,8 @@ int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
struct qxl_device *qdev;
int r;
 
-   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) {
-   pr_info("%s: vma->vm_pgoff (%ld) < DRM_FILE_PAGE_OFFSET\n",
-   __func__, vma->vm_pgoff);
+   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
return -EINVAL;
-   }
 
file_priv = filp->private_data;
qdev = file_priv->minor->dev->dev_private;
-- 
2.14.1

[PATCH][V2] drm: qxl: remove pr_info message, stops log spamming

[Colin King]

From: Colin Ian King 

Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:

int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");

for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED, fd, 0);
if (m != MAP_FAILED)
munmap(m, 4096);
}
}

Stop the spamming by removing the pr_info message. Since the mmap'ing
returns -EINVAL there is no need for the pr_info message.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/qxl/qxl_ttm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 7ecf8a4b9fe6..0f50c0b25a58 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -123,11 +123,8 @@ int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
struct qxl_device *qdev;
int r;
 
-   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) {
-   pr_info("%s: vma->vm_pgoff (%ld) < DRM_FILE_PAGE_OFFSET\n",
-   __func__, vma->vm_pgoff);
+   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
return -EINVAL;
-   }
 
file_priv = filp->private_data;
qdev = file_priv->minor->dev->dev_private;
-- 
2.14.1

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Gerd Hoffmann]

On Tue, 2017-09-12 at 17:09 +0300, Dan Carpenter wrote:
> On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> > That said, I'm not sure how useful the information is - perhaps
> > it's
> > better to drop it all together?
> 
> Or a WARN_ONCE().

It's userspace calling into the driver with invalid parameters.

IMO we should never WARN_ONCE() on something userspace can trigger.

I'd suggest to just drop the message altogether, simply throwing EINVAL
at userspace is perfectly fine IMHO.

cheers,
  Gerd

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Gerd Hoffmann]

On Tue, 2017-09-12 at 17:09 +0300, Dan Carpenter wrote:
> On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> > That said, I'm not sure how useful the information is - perhaps
> > it's
> > better to drop it all together?
> 
> Or a WARN_ONCE().

It's userspace calling into the driver with invalid parameters.

IMO we should never WARN_ONCE() on something userspace can trigger.

I'd suggest to just drop the message altogether, simply throwing EINVAL
at userspace is perfectly fine IMHO.

cheers,
  Gerd

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Dan Carpenter]

On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> That said, I'm not sure how useful the information is - perhaps it's
> better to drop it all together?

Or a WARN_ONCE().

regards,
dan carpenter

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Dan Carpenter]

On Tue, Sep 12, 2017 at 03:02:04PM +0100, Emil Velikov wrote:
> That said, I'm not sure how useful the information is - perhaps it's
> better to drop it all together?

Or a WARN_ONCE().

regards,
dan carpenter

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Emil Velikov]

Hi Colin,

On 12 September 2017 at 10:45, Colin King  wrote:
> From: Colin Ian King 
>
> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
> log with qxl_mmap information messages. The following example code
> illustrates this:
>
> int main(void)
> {
> int fd = open("/dev/dri/card0", O_RDONLY);
> if (fd == -1)
> err(1, "open failed");
>
> for (;;) {
> void *m = mmap(NULL, 4096, PROT_READ,
> MAP_SHARED, fd, 0);
> if (m != MAP_FAILED)
> munmap(m, 4096);
> }
> }
>
> Reduce the spamming by ratelimiting the pr_info messages.
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index 7ecf8a4b9fe6..6502e699f462 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -124,7 +124,7 @@ int qxl_mmap(struct file *filp, struct vm_area_struct 
> *vma)
> int r;
>
> if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) {
> -   pr_info("%s: vma->vm_pgoff (%ld) < DRM_FILE_PAGE_OFFSET\n",
> +   pr_info_ratelimited("%s: vma->vm_pgoff (%ld) < 
> DRM_FILE_PAGE_OFFSET\n",
Quick grep suggests that only qxl and vmwgfx produce any output in
this case, likely for the reasons you mentioned.

That said, I'm not sure how useful the information is - perhaps it's
better to drop it all together? Regardless of the route taken, vmwgfx
could use a similar fix.

HTH
Emil

Re: [PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Emil Velikov]

Hi Colin,

On 12 September 2017 at 10:45, Colin King  wrote:
> From: Colin Ian King 
>
> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
> log with qxl_mmap information messages. The following example code
> illustrates this:
>
> int main(void)
> {
> int fd = open("/dev/dri/card0", O_RDONLY);
> if (fd == -1)
> err(1, "open failed");
>
> for (;;) {
> void *m = mmap(NULL, 4096, PROT_READ,
> MAP_SHARED, fd, 0);
> if (m != MAP_FAILED)
> munmap(m, 4096);
> }
> }
>
> Reduce the spamming by ratelimiting the pr_info messages.
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index 7ecf8a4b9fe6..6502e699f462 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -124,7 +124,7 @@ int qxl_mmap(struct file *filp, struct vm_area_struct 
> *vma)
> int r;
>
> if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) {
> -   pr_info("%s: vma->vm_pgoff (%ld) < DRM_FILE_PAGE_OFFSET\n",
> +   pr_info_ratelimited("%s: vma->vm_pgoff (%ld) < 
> DRM_FILE_PAGE_OFFSET\n",
Quick grep suggests that only qxl and vmwgfx produce any output in
this case, likely for the reasons you mentioned.

That said, I'm not sure how useful the information is - perhaps it's
better to drop it all together? Regardless of the route taken, vmwgfx
could use a similar fix.

HTH
Emil

[PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Colin King]

From: Colin Ian King 

Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:

int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");

for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED, fd, 0);
if (m != MAP_FAILED)
munmap(m, 4096);
}
}

Reduce the spamming by ratelimiting the pr_info messages.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 7ecf8a4b9fe6..6502e699f462 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -124,7 +124,7 @@ int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
int r;
 
if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) {
-   pr_info("%s: vma->vm_pgoff (%ld) < DRM_FILE_PAGE_OFFSET\n",
+   pr_info_ratelimited("%s: vma->vm_pgoff (%ld) < 
DRM_FILE_PAGE_OFFSET\n",
__func__, vma->vm_pgoff);
return -EINVAL;
}
-- 
2.14.1

[PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming

[Colin King]

From: Colin Ian King 

Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:

int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");

for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED, fd, 0);
if (m != MAP_FAILED)
munmap(m, 4096);
}
}

Reduce the spamming by ratelimiting the pr_info messages.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 7ecf8a4b9fe6..6502e699f462 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -124,7 +124,7 @@ int qxl_mmap(struct file *filp, struct vm_area_struct *vma)
int r;
 
if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET)) {
-   pr_info("%s: vma->vm_pgoff (%ld) < DRM_FILE_PAGE_OFFSET\n",
+   pr_info_ratelimited("%s: vma->vm_pgoff (%ld) < 
DRM_FILE_PAGE_OFFSET\n",
__func__, vma->vm_pgoff);
return -EINVAL;
}
-- 
2.14.1

[PATCH 4.2 028/120] staging: rtl8192e: Fix log spamming in rtl8192_hard_data_xmit

[Greg Kroah-Hartman]

4.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Mateusz Kulikowski 

commit 435009bba4d0449b611bc24ae5c9636ac5b2a00e upstream.

This patch fixes issue generated by commit ca93dcba3a92
("staging: rtl8192e: Remove assert() macro")

One negation was missed in conversion, therefore
asserted message was always printed.
For 1MB file downloaded via http, ~500 messages
were generated.

Signed-off-by: Mateusz Kulikowski 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1826,8 +1826,8 @@ void rtl8192_hard_data_xmit(struct sk_bu
return;
}
 
-   if (queue_index != TXCMD_QUEUE)
-   netdev_warn(dev, "%s(): queue index != TXCMD_QUEUE\n",
+   if (queue_index == TXCMD_QUEUE)
+   netdev_warn(dev, "%s(): queue index == TXCMD_QUEUE\n",
__func__);
 
memcpy((unsigned char *)(skb->cb), , sizeof(dev));


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4.2 028/120] staging: rtl8192e: Fix log spamming in rtl8192_hard_data_xmit

[Greg Kroah-Hartman]

4.2-stable review patch.  If anyone has any objections, please let me know.

--

From: Mateusz Kulikowski 

commit 435009bba4d0449b611bc24ae5c9636ac5b2a00e upstream.

This patch fixes issue generated by commit ca93dcba3a92
("staging: rtl8192e: Remove assert() macro")

One negation was missed in conversion, therefore
asserted message was always printed.
For 1MB file downloaded via http, ~500 messages
were generated.

Signed-off-by: Mateusz Kulikowski 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1826,8 +1826,8 @@ void rtl8192_hard_data_xmit(struct sk_bu
return;
}
 
-   if (queue_index != TXCMD_QUEUE)
-   netdev_warn(dev, "%s(): queue index != TXCMD_QUEUE\n",
+   if (queue_index == TXCMD_QUEUE)
+   netdev_warn(dev, "%s(): queue index == TXCMD_QUEUE\n",
__func__);
 
memcpy((unsigned char *)(skb->cb), , sizeof(dev));


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: rtl8192e: Fix log spamming in rtl8192_hard_data_xmit

[Mateusz Kulikowski]

This patch fixes issue generated by commit ca93dcba3a92
("staging: rtl8192e: Remove assert() macro")

One negation was missed in conversion, therefore
asserted message was always printed.
For 1MB file downloaded via http, ~500 messages
were generated.

Signed-off-by: Mateusz Kulikowski 
---

Notes:
This patch (probably) doesn't have to be applied urgently.
Modern distros are not outputting kernel log to console,
so even though driver would spam dmesg, it should not cause
performance drawbacks.

Target tested and verified that performance in fact improves,
at least on my configuration (logs are printed on console
and via netconsole).

Sorry I didn't catch that earlier - either during original
submission or later on - I didn't checked transmission
speeds as my area has some heavy wifi pollution.

 drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index c868cb37..d6b46df 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1642,8 +1642,8 @@ static void rtl8192_hard_data_xmit(struct sk_buff *skb, 
struct net_device *dev,
return;
}
 
-   if (queue_index != TXCMD_QUEUE)
-   netdev_warn(dev, "%s(): queue index != TXCMD_QUEUE\n",
+   if (queue_index == TXCMD_QUEUE)
+   netdev_warn(dev, "%s(): queue index == TXCMD_QUEUE\n",
__func__);
 
memcpy((unsigned char *)(skb->cb), , sizeof(dev));
-- 
1.8.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: rtl8192e: Fix log spamming in rtl8192_hard_data_xmit

[Mateusz Kulikowski]

This patch fixes issue generated by commit ca93dcba3a92
(staging: rtl8192e: Remove assert() macro)

One negation was missed in conversion, therefore
asserted message was always printed.
For 1MB file downloaded via http, ~500 messages
were generated.

Signed-off-by: Mateusz Kulikowski mateusz.kulikow...@gmail.com
---

Notes:
This patch (probably) doesn't have to be applied urgently.
Modern distros are not outputting kernel log to console,
so even though driver would spam dmesg, it should not cause
performance drawbacks.

Target tested and verified that performance in fact improves,
at least on my configuration (logs are printed on console
and via netconsole).

Sorry I didn't catch that earlier - either during original
submission or later on - I didn't checked transmission
speeds as my area has some heavy wifi pollution.

 drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index c868cb37..d6b46df 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -1642,8 +1642,8 @@ static void rtl8192_hard_data_xmit(struct sk_buff *skb, 
struct net_device *dev,
return;
}
 
-   if (queue_index != TXCMD_QUEUE)
-   netdev_warn(dev, %s(): queue index != TXCMD_QUEUE\n,
+   if (queue_index == TXCMD_QUEUE)
+   netdev_warn(dev, %s(): queue index == TXCMD_QUEUE\n,
__func__);
 
memcpy((unsigned char *)(skb-cb), dev, sizeof(dev));
-- 
1.8.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: log spamming

[Chris Snook]

Gene Heskett wrote:

Greetings;

I just rebooted to a new config of 2.6.24, basically trying to strip out the 
building of modules I don't use.  And I enabled a couple of checks that 
weren't checked in the kernel-hacking menu.  .config posted on request.


Now the messages log is being spammed at 2-5 second intervals by these:
Feb  1 10:41:08 coyote kernel: [ 3085.501037] MCE: The hardware reports a non 
fatal, correctable incident occurred on CPU 0.

Feb  1 10:41:08 coyote kernel: [ 3085.501042] Bank 1: d4004152
Feb  1 10:41:08 coyote kernel: [ 3085.501045] MCE: The hardware reports a non 
fatal, correctable incident occurred on CPU 0.

Feb  1 10:41:08 coyote kernel: [ 3085.501048] Bank 2: d400417a

Always the same 2 addresses.  Is this telling me I should be running memtest86 
for a couple of cycles?


Those two addresses are in the same cache line, but they are *not* in the same 
128-bit ECC block.  This is probably a northbridge problem, not a RAM problem. 
It's not necessarily a hardware problem.  I wouldn't be surprised if you swapped 
CPUs and still got the same result, due to BIOS misconfiguration.


-- Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

log spamming

[Gene Heskett]

Greetings;

I just rebooted to a new config of 2.6.24, basically trying to strip out the 
building of modules I don't use.  And I enabled a couple of checks that 
weren't checked in the kernel-hacking menu.  .config posted on request.

Now the messages log is being spammed at 2-5 second intervals by these:
Feb  1 10:41:08 coyote kernel: [ 3085.501037] MCE: The hardware reports a non 
fatal, correctable incident occurred on CPU 0.
Feb  1 10:41:08 coyote kernel: [ 3085.501042] Bank 1: d4004152
Feb  1 10:41:08 coyote kernel: [ 3085.501045] MCE: The hardware reports a non 
fatal, correctable incident occurred on CPU 0.
Feb  1 10:41:08 coyote kernel: [ 3085.501048] Bank 2: d400417a

Always the same 2 addresses.  Is this telling me I should be running memtest86 
for a couple of cycles?

Thanks.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"It is the creationists who blasphemously are claiming that God is cheating
 us in a stupid way."
-- J. W. Nienhuys
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: log spamming

[Chris Snook]

Gene Heskett wrote:

Greetings;

I just rebooted to a new config of 2.6.24, basically trying to strip out the 
building of modules I don't use.  And I enabled a couple of checks that 
weren't checked in the kernel-hacking menu.  .config posted on request.


Now the messages log is being spammed at 2-5 second intervals by these:
Feb  1 10:41:08 coyote kernel: [ 3085.501037] MCE: The hardware reports a non 
fatal, correctable incident occurred on CPU 0.

Feb  1 10:41:08 coyote kernel: [ 3085.501042] Bank 1: d4004152
Feb  1 10:41:08 coyote kernel: [ 3085.501045] MCE: The hardware reports a non 
fatal, correctable incident occurred on CPU 0.

Feb  1 10:41:08 coyote kernel: [ 3085.501048] Bank 2: d400417a

Always the same 2 addresses.  Is this telling me I should be running memtest86 
for a couple of cycles?


Those two addresses are in the same cache line, but they are *not* in the same 
128-bit ECC block.  This is probably a northbridge problem, not a RAM problem. 
It's not necessarily a hardware problem.  I wouldn't be surprised if you swapped 
CPUs and still got the same result, due to BIOS misconfiguration.


-- Chris
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

excessive IDE log spamming

[Ray Lee]

ray:/var/log$ grep ' 08:' messages
Jul  8 08:00:00 orca kernel: [7033724.854000] hdc: ATAPI reset complete
Jul  8 08:00:00 orca kernel: [7033724.854000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033724.854000] ide: failed opcode was: unknown
Jul  8 08:00:00 orca kernel: [7033724.904000] hdc: ATAPI reset complete
Jul  8 08:00:00 orca kernel: [7033724.904000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033724.904000] ide: failed opcode was: unknown
Jul  8 08:00:00 orca kernel: [7033724.904000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033724.904000] ide: failed opcode was: unknown
Jul  8 08:00:00 orca kernel: [7033724.954000] hdc: ATAPI reset complete
Jul  8 08:00:00 orca kernel: [7033724.954000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033724.954000] ide: failed opcode was: unknown
Jul  8 08:00:00 orca kernel: [7033725.004000] hdc: ATAPI reset complete
Jul  8 08:00:00 orca kernel: [7033725.004000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033725.004000] ide: failed opcode was: unknown
Jul  8 08:00:02 orca kernel: [7033727.006000] hdc: status error: status=0x20 { 
DeviceFault }

/var/log/{messages,syslog,kern.log} are each growing at about 4
megabytes an hour. That's nearly a third of a gig per day. I may be a
bit dense, but honest, I got the hint the first meg.

/dev/hdc points to my Plextor CD/RW drive. I'm not sure when this
started; it took some time before I noticed my hard drive filling up
(they're pretty big these days). I'll be rebooting here soon, which I
imagine will fix the problem.

Using Ubuntu's 2.6.12 kernel, so there's the outside chance that odd
vendor patches are doing unhappy things.

Ray

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

excessive IDE log spamming

[Ray Lee]

ray:/var/log$ grep ' 08:' messages
Jul  8 08:00:00 orca kernel: [7033724.854000] hdc: ATAPI reset complete
Jul  8 08:00:00 orca kernel: [7033724.854000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033724.854000] ide: failed opcode was: unknown
Jul  8 08:00:00 orca kernel: [7033724.904000] hdc: ATAPI reset complete
Jul  8 08:00:00 orca kernel: [7033724.904000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033724.904000] ide: failed opcode was: unknown
Jul  8 08:00:00 orca kernel: [7033724.904000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033724.904000] ide: failed opcode was: unknown
Jul  8 08:00:00 orca kernel: [7033724.954000] hdc: ATAPI reset complete
Jul  8 08:00:00 orca kernel: [7033724.954000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033724.954000] ide: failed opcode was: unknown
Jul  8 08:00:00 orca kernel: [7033725.004000] hdc: ATAPI reset complete
Jul  8 08:00:00 orca kernel: [7033725.004000] hdc: status error: status=0x20 { 
DeviceFault }
Jul  8 08:00:00 orca kernel: [7033725.004000] ide: failed opcode was: unknown
Jul  8 08:00:02 orca kernel: [7033727.006000] hdc: status error: status=0x20 { 
DeviceFault }

/var/log/{messages,syslog,kern.log} are each growing at about 4
megabytes an hour. That's nearly a third of a gig per day. I may be a
bit dense, but honest, I got the hint the first meg.

/dev/hdc points to my Plextor CD/RW drive. I'm not sure when this
started; it took some time before I noticed my hard drive filling up
(they're pretty big these days). I'll be rebooting here soon, which I
imagine will fix the problem.

Using Ubuntu's 2.6.12 kernel, so there's the outside chance that odd
vendor patches are doing unhappy things.

Ray

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/