Re: [PATCH 01/15] EDAC: make device_type const

[Borislav Petkov]

On Sat, Aug 19, 2017 at 01:52:12PM +0530, Bhumika Goyal wrote:
> Make these const as they are only stored in the type field of a device
> structure, which is const.
> Done using Coccinelle.
> 
> Signed-off-by: Bhumika Goyal 
> ---
>  drivers/edac/edac_mc_sysfs.c | 8 
>  drivers/edac/i7core_edac.c   | 4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Borislav Petkov]

On Fri, Jan 13, 2017 at 05:08:34PM +0100, Nicolas Dichtel wrote:
> Le 13/01/2017 à 16:43, David Howells a écrit :
> >> -header-y += msr-index.h
> > 
> > I see it on my desktop as /usr/include/asm/msr-index.h and it's been there 
> > at
> > least four years - and as such it's part of the UAPI.  I don't think you can
> > remove it unless you can guarantee there are no userspace users.
> I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks 
> me
> to un-export it.
> 
> I will follow the maintainer decision.

I'm not the maintainer. I simply think that exporting that file was
wrong because it if we change something in it, we will break userspace.
And that should not happen - if userspace needs MSRs, it should do its
own defines.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/7] x86: put msr-index.h in uapi

[Borislav Petkov]

On Fri, Jan 06, 2017 at 10:43:56AM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.

It should rather not be exported - please remove it from
arch/x86/include/uapi/asm/Kbuild instead.

Thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()

[Borislav Petkov]

On Mon, Jun 22, 2015 at 03:01:38AM +0200, Luis R. Rodriguez wrote:
 We can certainly replace the WARN() with pr_warn(), I don't see
 how its confusing though as its a run time real issue. Either
 way whatever you recommend is fine by me.

Yeah, it confused the 0day robot at least. :-)

But maybe because it cannot really read. But I've experienced cases
where people don't read too, see *a* splat and raise the alarm. So yeah,
I think a simple pr_warn would be much better.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in

Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()

[Borislav Petkov]

On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote:
 Nope, well the driver requires huge amounts of work to work with PAT,
 that work will likely never be done, so hence the warning. Its our
 compromise as only 2 drivers will live on Linux like this and they are
 both old and rare.

Hmm, so wasn't the possibility discussed to fail loading instead and
issue a single-line pr_warn() when PAT is enabled? Those big WARN()
splats will only confuse people...

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in

Re: [x86/mm/pat, drivers/media/ivtv] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 ivtvfb_init()

[Borislav Petkov]

On Sat, Jun 20, 2015 at 03:17:56PM +0800, Fengguang Wu wrote:
 Greetings,
 
 0day kernel testing robot got the below dmesg and the first bad commit is
 
 git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
 
 commit 1bf1735b478008c30acaff18ec6f4a3ff211c28a
 Author: Luis R. Rodriguez mcg...@suse.com
 AuthorDate: Mon Jun 15 10:28:16 2015 +0200
 Commit: Ingo Molnar mi...@kernel.org
 CommitDate: Thu Jun 18 11:23:41 2015 +0200
 
 x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT 
 disabled

...

 [   12.956506] ivtv: Start initialization, version 1.4.3
 [   12.958238] ivtv: End initialization
 [   12.959438] [ cut here ]
 [   12.974076] WARNING: CPU: 0 PID: 1 at drivers/media/pci/ivtv/ivtvfb.c:1270 
 ivtvfb_init+0x32/0xa3()
 [   12.978017] ivtvfb needs PAT disabled, boot with nopat kernel parameter

Warning says it all. You need to boot with nopat. Apparently, those
devices are very seldom now and users should boot with nopat.

Luis, what is the plan, is this driver supposed to be converted to
reserve_memtype(..., _PAGE_CACHE_MODE_WC, ...) at some point?

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in

Re: [PATCH v6 2/3] IB/ipath: add counting for MTRR

[Borislav Petkov]

On Thu, Jun 11, 2015 at 10:50:01AM -0700, Luis R. Rodriguez wrote:
 From: Luis R. Rodriguez mcg...@suse.com
 
 There is no good reason not to, we eventually delete it as well.
 
 Cc: Toshi Kani toshi.k...@hp.com
 Cc: Roland Dreier rol...@kernel.org
 Cc: Sean Hefty sean.he...@intel.com
 Cc: Hal Rosenstock hal.rosenst...@gmail.com
 Cc: Suresh Siddha sbsid...@gmail.com
 Cc: Ingo Molnar mi...@elte.hu
 Cc: Thomas Gleixner t...@linutronix.de
 Cc: Juergen Gross jgr...@suse.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: Andy Lutomirski l...@amacapital.net
 Cc: Dave Airlie airl...@redhat.com
 Cc: Antonino Daplas adap...@gmail.com
 Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: infinip...@intel.com
 Cc: linux-r...@vger.kernel.org
 Cc: linux-fb...@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org
 Signed-off-by: Luis R. Rodriguez mcg...@suse.com
 ---
  drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c 
 b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
 index 4ad0b93..70c1f3a 100644
 --- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
 +++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
 @@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
  (addr %llx, len=0x%llx)\n,
  (unsigned long long) pioaddr,
  (unsigned long long) piolen);
 - cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
 + cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
   if (cookie  0) {
   {
   dev_info(dd-pcidev-dev,
 --

Doug, ack?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH bp] EDAC, mce_amd_inj: inj_type can be static

[Borislav Petkov]

On Fri, Jun 05, 2015 at 07:24:26PM +0800, kbuild test robot wrote:
 
 Signed-off-by: Fengguang Wu fengguang...@intel.com
 ---
  mce_amd_inj.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/edac/mce_amd_inj.c b/drivers/edac/mce_amd_inj.c
 index 2a0c829..46a6b0e 100644
 --- a/drivers/edac/mce_amd_inj.c
 +++ b/drivers/edac/mce_amd_inj.c
 @@ -44,7 +44,7 @@ static const char * const flags_options[] = {
  };
  
  /* Set default injection to SW_INJ */
 -enum injection_type inj_type = SW_INJ;
 +static enum injection_type inj_type = SW_INJ;
  
  #define MCE_INJECT_SET(reg)  \
  static int inj_##reg##_set(void *data, u64 val)  
 \

Thanks kbuild test robot, applied!

:-D

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7 linux-next] drivers: remove deprecated IRQF_DISABLED

[Borislav Petkov]

On Mon, Oct 06, 2014 at 05:35:47PM +0200, Fabian Frederick wrote:
 This small patchset removes IRQF_DISABLED from drivers branch.
 
 See include/linux/interrupt.h:
 This flag is a NOOP and scheduled to be removed
 
 Note: (cross)compiled but untested.
 
 Fabian Frederick (7):
   mv64x60_edac: remove deprecated IRQF_DISABLED
   ppc4xx_edac: remove deprecated IRQF_DISABLED

For the EDAC bits already applied Michael's patch:

https://lkml.kernel.org/r/1412159043-7348-1-git-send-email-michael.opdenac...@free-electrons.com

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7 linux-next] drivers: remove deprecated IRQF_DISABLED

[Borislav Petkov]

On Mon, Oct 06, 2014 at 08:33:00PM +0200, Fabian Frederick wrote:
    You're right, I guess we can forget this patchset.
 I didn't see it was already done. (nothing in linux-next yet).

Not the whole patchset - I was replying only to your two patches
touching code in drivers/edac/. I don't know about the rest but yeah,
checking linux-next is always a good idea.

Also, did you CC the proper maintainers for the rest of your patches? If
not, do that and see what they have to say.

HTH.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: WARNING: at drivers/media/v4l2-core/videobuf2-core.c:2065 vb2_queue_init+0x74/0x142()

[Borislav Petkov]

On Fri, May 10, 2013 at 02:06:50PM +0200, Hans Verkuil wrote:
 Can you try this patch? This should fix it.

Yep, it does.

Tested-by: Borislav Petkov b...@suse.de

 diff --git a/drivers/media/parport/bw-qcam.c b/drivers/media/parport/bw-qcam.c
 index 06231b8..d12bd33 100644
 --- a/drivers/media/parport/bw-qcam.c
 +++ b/drivers/media/parport/bw-qcam.c
 @@ -687,6 +687,7 @@ static int buffer_finish(struct vb2_buffer *vb)
  
   parport_release(qcam-pdev);
   mutex_unlock(qcam-lock);
 + v4l2_get_timestamp(vb-v4l2_buf.timestamp);
   if (len != size)
   vb-state = VB2_BUF_STATE_ERROR;
   vb2_set_plane_payload(vb, 0, len);
 @@ -964,6 +965,7 @@ static struct qcam *qcam_init(struct parport *port)
   q-drv_priv = qcam;
   q-ops = qcam_video_qops;
   q-mem_ops = vb2_vmalloc_memops;
 + q-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;

However, just FYI: I do trigger the warning in a guest and not on the
real hardware. So I can't really confirm whether _MONOTONIC is the
proper timestamp type or not. But it looks like you know what you're
doing. :-)

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Borislav Petkov]

On Sun, Oct 21, 2012 at 01:57:21AM +, Artem S. Tashkinov wrote:
 The freeze happens on my *host* Linux PC. For an experiment I decided
 to check if I could reproduce the freeze under a virtual machine - it
 turns out the Linux kernel running under it also freezes.

I know that - but a freeze != oops - at least not necessarily. Which
means it could very well be a different issue now that vbox is gone.

Or, it could be the same issue with different incarnations: with vbox
you get the corruptions and without it, you get the freezes. I'm
assuming you do the same flash player thing in both cases?

Here's a crazy idea: can you try to reproduce it in KVM?

Thanks.

-- 
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Borislav Petkov]

On Sun, Oct 21, 2012 at 11:59:36AM +, Artem S. Tashkinov wrote:
 http://imageshack.us/a/img685/9452/panicz.jpg
 
 list_del corruption. prev-next should be ... but was ...

Btw, this is one of the debug options I told you to enable.

 I cannot show you more as I have no serial console to use :( and the kernel
 doesn't have enough time to push error messages to rsyslog and fsync
 /var/log/messages

I already told you how to catch that oops: boot with pause_on_oops=600
on the kernel command line and photograph the screen when the first oops
happens. This'll show us where the problem begins.

-- 
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Borislav Petkov]

On Sun, Oct 21, 2012 at 07:49:01PM +, Artem S. Tashkinov wrote:
 I ran it this way: while :; do dmesg -c; done | scat /dev/sda11 (yes,
 straight to a hdd partition to eliminate a FS cache)

Well, I'm no fs guy but this should still go through the buffer cache. I
think the O_SYNC flag makes sure it all lands on the partition in time.
Oh well, it doesn't matter.

 Don't judge me harshly - I'm not a programmer.

If you wrote that and you're not a programmer, it certainly looks cool,
good job!.

 [ Btw, don't forget to free(buffer) at the end. ]

Also, there was a patchset recently which added a blockconsole method to
the kernel with which you can do something like that in a generic way.

Back to the issue at hand: it looks like ehci_hcd is causing some list
corruptions, maybe coming from the uvcvideo or whatever. I think the usb
people will have a better idea.

Btw, is there any particular reason you're running a 32-bit kernel?

Thanks.

-- 
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website

[Borislav Petkov]

]
 [  301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
 [  301.196606] set resolution quirk: cval-res = 384
 [  371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow 
 Control: RX
 [  390.729568] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule
 f5ade900 2296555[  390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 
 us]
 437 S Ii:1:003:7[  390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 
 [1/0 us]
  -115:128 16 
 f5ade900 2296566256 C Ii:1:003:7 -2:128 0
 [  391.100896] ehci_hcd :00:1f.5: reused qh f48d64c0 schedule
 [  391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
 f5ade900 2296926929 S Ii:1:003:7[  391.104889] usb 1-1: unlink 
 qh16-0001/f48d64c0 start 2 [1/0 us]
  -115:128 16 
 f5ade900 2296937889 C Ii:1:003:7 -2:128 0
 f5272300 2310382508 S Co:1:003:0 s 01 0b 0004 0001  0
 f5272300 2310407888 C Co:1:003:0 0 0
 f5272300 2310408051 S Co:1:003:0 s 22 01 0100 0086 0003 3 = 80bb00
 f5272300 2310412456 C Co:1:003:0 0 3 
 f5272300 2310412521 S Ci:1:003:0 s a2 81 0100 0086 0003 3 
 f5272300 2310415909 C Ci:1:003:0 0 0
 f5272300 2310418133 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 
 f5272600 2310418219 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 
 f52720c0 2310418239 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 
 f5272a80 2310418247 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 
 f5272480 2310418256 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 
 f52723c0 2310418264 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 
 f5272d80 2310418272 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 
 f5272b40 2310418280 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 
 
 Hard freeze with 100% CPU usage at this point as if some driver got into an
 infinite loop or something.
 
 All debug options from https://lkml.org/lkml/2012/10/20/116 are enabled, but
 serial console is empty.
 
 Best wishes,
 
 Artem
 
 
 On Oct 21, 2012, Borislav Petkov wrote: 
 
  I don't think that's the problem - I rather suspect the fact that he's
  using virtualbox which is causing random corruptions by writing to
  arbitrary locations.
  
  
  
  please remove virtualbox completely from your system, rebuild the kernel
  and make sure the virtualbox kernel modules don't get loaded - simply
  delete them so that they are completely gone; *and* *then* retest again.
 
 

-- 
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html