linux-kernel - Re: [PATCHv2] qla2xxx: Correct compilation issues when CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 15 Sep 2009 14:57:53 -0700
From:	Andrew Vasquez <andrew.vasquez@...gic.com>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Greg KH <greg@...ah.com>,
	James Bottomley <James.Bottomley@...e.de>,
	Linux SCSI Mailing List <linux-scsi@...r.kernel.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Giridhar Malavali <giridhar.malavali@...gic.com>,
	Ravi Anand <ravi.anand@...gic.com>,
	Lalit Chandivade <lalit.chandivade@...gic.com>
Subject: Re: [PATCHv2] qla2xxx: Correct compilation issues when
 CONFIG_MOUDLES=n.

On Tue, 15 Sep 2009, Kay Sievers wrote:
> On Tue, Sep 15, 2009 at 18:57, Greg KH <greg@...ah.com> wrote:
> > On Tue, Sep 15, 2009 at 10:47:11AM -0500, James Bottomley wrote:
> >> On Tue, 2009-09-15 at 08:33 -0700, Greg KH wrote:
> >> > On Sat, Sep 12, 2009 at 09:30:07AM -0500, James Bottomley wrote:
> >> > > On Fri, 2009-09-11 at 21:33 -0700, Greg KH wrote:
> >> > > > On Fri, Sep 11, 2009 at 07:56:23PM -0700, Andrew Vasquez wrote:
> >> > > > > On Fri, 11 Sep 2009, Greg KH wrote:
> >> > > > >
> >> > > > > > On Fri, Sep 11, 2009 at 05:38:08PM -0700, Andrew Vasquez wrote:
> >> > > > > > > Randy Dunlap noted:
> >> > > > > > >
> >> > > > > > >   when CONFIG_MODULES=n:
> >> > > > > > >
> >> > > > > > >   drivers/scsi/qla2xxx/qla_os.c:2685: error: dereferencing pointer to incomplete type
> >> > > > > > >
> >> > > > > > >   in
> >> > > > > > >
> >> > > > > > >   kobject_uevent_env(&(&vha->hw->pdev->driver->driver)->owner->mkobj.kobj,
> >> > > > > > >           KOBJ_CHANGE, envp);
> >> > > > > > >
> >> > > > > > > Trigger kobject event on the 'struct device' hanging off the pci_dev.
> >> > > > > >
> >> > > > > > Um, why?  What are you trying to do here?  kobject change should not be
> >> > > > > > for a device, or a "normal" kobject.
> >> > > > > >
> >> > > > > > What do you expect userspace to do with this?  Where have you documented
> >> > > > > > it?
> >> > > > >
> >> > > > > The purpose was described here:
> >> > > > >
> >> > > > >       http://article.gmane.org/gmane.linux.scsi/54155
> >> > > > >
> >> > > > > Basically we'd like to instruct user-space to retrieve a blob of data
> >> > > > > automatically.
> >> > > >
> >> > > > Hm, like a firmware object perhaps?
> >> > > >
> >> > > > > Original implementation used the kboject hanging off
> >> > > > > the module which does not exist when CONFIG_MODULES=n.  It was
> >> > > > > suggested that perhaps an alternative would be to use 'struct device'
> >> > > > > kobj.  Any tips on how to trigger such a driver-specific event,
> >> > > > > perhaps a dedicated kobject exported by the driver itself???
> >> > > >
> >> > > > Why not use the firmware interface for it, that is what it is designed
> >> > > > for, and you will not have to craft any new udev rules.
> >> > >
> >> > > The data is going the wrong way to use the current firmware interface,
> >> > > which is designed to load data from userspace into the kernel.  For this
> >> > > interface, we want the data to go the other way (i.e. the kernel has a
> >> > > blob of dump data it would like userspace to save if it can).
> >> >
> >> > Ick.
> >>
> >> It's a natural debugging event ... the user can simply program the
> >> system to discard the dump.
> >>
> >> > > I'd be amenable to updating the firmware interface to do this, but it
> >> > > looks like adding a completely new codepath, which it's not clear even
> >> > > belongs there.
> >> >
> >> > Well, I don't think it deserves a kobject change event, as that means
> >> > something a bit different to userspace today, right?
> >>
> >> Well, the documentation (in include/linux/kobject.h) does say that
> >> KOBJ_CHANGED is the dumping ground for events that don't match anything
> >> else, which this one seems to qualify as.  What else do you suggest?
> >
> > Ok, I can't think of anything else at the moment, sorry.
> 
> Wouldn't kernel/kmod.c :: call_usermodehelper_pipe() somehow fit for
> that interface?

The only current consumer of call_usermodehelper_pipe() is
fs/exec.c::do_coredump() and it appears to manipulate the blob of data
via file-level operations.  Would this be a 'notification'
alternative?  Or, are you suggesting the whole process be redone (both
notification and blob-transfer)?  Uevent notifications with a udev
user-space front-end appears to be a much more simplified and flexible
mechanism.

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