Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO

2017-12-19 Thread Borislav Petkov
On Tue, Dec 19, 2017 at 10:51:14AM -0800, Joe Perches wrote: > > The reason for the code churn being? > > Consistency for easier grep by use-type. Please explain that in the commit message so that we know why it was changed. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid to

Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO

2017-12-19 Thread Borislav Petkov
On Tue, Dec 19, 2017 at 10:15:09AM -0800, Joe Perches wrote: > Convert DEVICE_ATTR uses to DEVICE_ATTR_WO where possible. > > Done with perl script: > > $ git grep -w --name-only DEVICE_ATTR | \ > xargs perl -i -e 'local $/; while (<>) { > s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IWUSR\s*

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

2017-08-20 Thread 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_

Section mismatch in reference from the function generic_NCR5380_isa_match()

2016-10-29 Thread Borislav Petkov
Hi, I'm seeing this during randconfig builds: WARNING: vmlinux.o(.text+0x1588439): Section mismatch in reference from the function generic_NCR5380_isa_match() to the function .init.text:probe_intr() The function generic_NCR5380_isa_match() references the function __init probe_intr(). This is oft

Re: [patch v2] arcmsr: buffer overflow in arcmsr_iop_message_xfer()

2016-09-23 Thread Borislav Petkov
ue. Yap, Tomas said the kfree was missing on the error path but can we simplify this further by doing the user_len check first so that the kfree() is not even needed? Patch ontop: --- From: Borislav Petkov Date: Fri, 23 Sep 2016 13:04:51 +0200 Subject: [PATCH] scsi: arcmsr: Simplify user_len checki

Re: hpsa failure with 4.3.0-rc1

2015-09-30 Thread Borislav Petkov
On Wed, Sep 30, 2015 at 09:40:50AM +0200, Hannes Reinecke wrote: > Hi all, > > trying to boot 4.3.0-rc1 on a system with hpsa results in a swiotlb > failure: > > hpsa :22:00.0: Logical aborts not supported > hpsa :22:00.0: HP SSD Smart Path aborts not supported > hpsa :22:00.0: swiotl

Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD

2014-06-16 Thread Borislav Petkov
On Mon, Jun 16, 2014 at 12:33:55PM +0200, Thomas Schwinge wrote: > The power supply and/or mainboard didn't "wake up" after a recent power > cycle. As both these aren't standard form factors (and the > machine/architecture had some issues, as discussed, and see also >

Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD

2014-06-16 Thread Borislav Petkov
Hi Thomas, On Mon, Jun 16, 2014 at 09:13:20AM +0200, Thomas Schwinge wrote: > The problem "solved itself": the machine recently died of hardware > failure. ;-| How convenient. :-P What happened? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To uns

Re: [PATCH] checkpatch: Make camelcase test --strict and less noisy

2013-05-01 Thread Borislav Petkov
On Thu, Apr 11, 2013 at 07:45:03AM -0700, Joe Perches wrote: > CamelCase tests are a bit noisy against certain > types of code acceptable to some kernel developers. > > Make the test applicable only with --strict. > > Do not bleat a message on nominally acceptable > CamelCase uses that are separa

Re: checkpatch: kill the bogus camelcase check

2013-04-10 Thread Borislav Petkov
On Wed, Apr 10, 2013 at 08:07:41AM -0700, James Bottomley wrote: > On Wed, 2013-04-10 at 16:52 +0200, Borislav Petkov wrote: > > On Wed, Apr 10, 2013 at 07:35:58AM -0700, Joe Perches wrote: > > > or maybe exclude drivers/scsi and include/scsi/ > > > > and arch/x86/k

Re: checkpatch: kill the bogus camelcase check

2013-04-10 Thread Borislav Petkov
On Wed, Apr 10, 2013 at 07:35:58AM -0700, Joe Perches wrote: > or maybe exclude drivers/scsi and include/scsi/ and arch/x86/kvm/emulate.c -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-s

Re: SYSFS "errors"

2013-02-19 Thread Borislav Petkov
rate where supported > > Currently, sdram_scrub_rate sysfs node is created even if the device > doesn't support get/set the scub rate. Change the logic to only > create this device node when the operation is supported. > > Reported-by: Felipe Balbi > Signed-off-by: Ma

Re: SYSFS "errors"

2013-02-19 Thread Borislav Petkov
On Tue, Feb 19, 2013 at 02:58:07PM +0100, Hannes Reinecke wrote: > Please consider adding a default attribute which return '-EINVAL' or > somesuch when the function pointers are not set. But _not_ adding it > via device_create_file(). That's evil. This is what we do now. We probably could add the

Re: SYSFS "errors"

2013-02-19 Thread Borislav Petkov
On Tue, Feb 19, 2013 at 10:50:48AM -0300, Mauro Carvalho Chehab wrote: > It is actually worse, as if someone is using a C code to open the device > with > fp = open ("/sys/devices/system/edac/mc/mc0/sdram_scrub_rate", O_RDWR); > > It will now start to fail if the device doesn't have both per

Re: SYSFS "errors"

2013-02-19 Thread Borislav Petkov
On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote: > because changing the permission will cause the same issue: Actually, I take that back. Mauro's patch will already create the file anyway: if (mci->set_sdram_scrub_rate || mci->get_sdram_scrub_rate) Adjusting the permissions

Re: SYSFS "errors"

2013-02-19 Thread Borislav Petkov
On Tue, Feb 19, 2013 at 03:15:00PM +0200, Felipe Balbi wrote: > what's the problem with that ? Not a problem - simply annoying. $ ./test.sh cat: /path/to/file/that/doesnt/exist.txt: No such file or directory Setting scrubrate to: I'm sure someone would ask themselves why all of a sudden the file

Re: SYSFS "errors"

2013-02-19 Thread Borislav Petkov
On Tue, Feb 19, 2013 at 09:46:40AM -0300, Mauro Carvalho Chehab wrote: > Ah, now I see what you're meaning. That would require to dynamically > create a per-mci DEVICE_ATTR(). Dude, look at the code, we do that already. And you're using it with dev_attr_sdram_scrub_rate. Simply change the permiss

Re: SYSFS "errors"

2013-02-19 Thread Borislav Petkov
On Tue, Feb 19, 2013 at 09:16:10AM -0300, Mauro Carvalho Chehab wrote: > I'm not sure if is there a way to pass fs permissions to something similar > to device_create_file(). struct device_attribute.attr.mode? I.e., second arg. > On both cases, an error will happen at open: > - if file does

Re: SYSFS "errors"

2013-02-19 Thread Borislav Petkov
On Tue, Feb 19, 2013 at 08:11:49AM -0300, Mauro Carvalho Chehab wrote: > > > I remember I saw some discussions about it in the past at bluesmoke ML, > > > saying that -ENODEV is the expected behavior when this is not supported. > > > > > > Changing from -ENODEV to "N/A" will break anything that wo

Re: SYSFS "errors"

2013-02-18 Thread Borislav Petkov
On Mon, Feb 18, 2013 at 02:26:18PM -0800, Greg KH wrote: > I don't know, it depends on if userspace can handle this properly or > not. What tools rely on this sysfs file? WHat happens when they get a > non-number in the file? I'm not aware of any, frankly speaking. If there are any, those tools s

Re: SYSFS "errors"

2013-02-18 Thread Borislav Petkov
On Mon, Feb 18, 2013 at 01:54:34PM -0800, Greg KH wrote: > Because sysfs is "one value per file" the lack of a file showing up > shouldn't cause any userspace tools any problems, that is why we did > things this way. > > But, of course, userspace programmers do know how to mess things up... How ab

Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD

2012-09-17 Thread Borislav Petkov
On Thu, Sep 13, 2012 at 02:58:25PM +0200, Borislav Petkov wrote: > Here's the script, let me know how it goes: Here's a more correct version. I'm not saying yours won't work based on the rdmsr and setpci output on your box, but here's a version which should pay atten

Re: Linux kernel crash (3.2.0-2-amd64) when trying to play audio CD

2012-09-13 Thread Borislav Petkov
On Fri, Sep 07, 2012 at 11:14:33AM +0200, Thomas Schwinge wrote: > I have now finally been able to check this, and yes, I'm already using > the latest version of the BIOS, which is Phoenix cME FirstBIOS Desktop > Pro version 5.00 R1.07.2264.A1 (a.k.a. 5.00.1.07, 25.04.2006) for > Fujitsu Siemens E