Date:	Fri, 14 Nov 2014 17:19:55 +0100 (CET)
From:	Fabian Frederick <fabf@...net.be>
To:	Jens Axboe <axboe@...nel.dk>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the block tree



> On 11 November 2014 at 16:27 Jens Axboe <axboe@...nel.dk> wrote:
>
>
> On 2014-11-11 04:20, Fabian Frederick wrote:
> >
> >
> >> On 11 November 2014 at 03:12 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >>
> >>
> >> Hi Jens,
> >>
> >> After merging the block tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> drivers/built-in.o: In function `cdrom_sysctl_handler':
> >> cdrom_sysctl.c:(.text+0x156d92): undefined reference to `cdrom_mutex'
> >> cdrom_sysctl.c:(.text+0x156da0): undefined reference to `cdrom_autoclose'
> >> cdrom_sysctl.c:(.text+0x156dae): undefined reference to `cdrom_autoeject'
> >> cdrom_sysctl.c:(.text+0x156dbc): undefined reference to `cdrom_debug'
> >> cdrom_sysctl.c:(.text+0x156dca): undefined reference to `cdrom_lockdoor'
> >> cdrom_sysctl.c:(.text+0x156dd8): undefined reference to
> >> `cdrom_check_media_type'
> >> cdrom_sysctl.c:(.text+0x156e0b): undefined reference to `cdrom_list'
> >> cdrom_sysctl.c:(.text+0x156e37): undefined reference to `cdrom_autoclose'
> >> cdrom_sysctl.c:(.text+0x156e57): undefined reference to `cdrom_autoeject'
> >> cdrom_sysctl.c:(.text+0x156e77): undefined reference to
> >> `cdrom_check_media_type'
> >> cdrom_sysctl.c:(.text+0x156ea4): undefined reference to `cdrom_lockdoor'
> >> cdrom_sysctl.c:(.text+0x156eb5): undefined reference to `cdrom_list'
> >> cdrom_sysctl.c:(.text+0x15702e): undefined reference to `cdrom_mutex'
> >> drivers/built-in.o: In function `cdrom_print_info.constprop.0':
> >> cdrom_sysctl.c:(.text+0x1570f3): undefined reference to `cdrom_list'
> >> cdrom_sysctl.c:(.text+0x157189): undefined reference to `cdrom_list'
> >> drivers/built-in.o: In function `cdrom_sysctl_info':
> >> cdrom_sysctl.c:(.text+0x1572c3): undefined reference to `cdrom_mutex'
> >> cdrom_sysctl.c:(.text+0x1576dc): undefined reference to `cdrom_mutex'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x157765): undefined reference to `cdrom_autoclose'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x157781): undefined reference to `cdrom_autoeject'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x15778e): undefined reference to `cdrom_debug'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x15779b): undefined reference to `cdrom_lockdoor'
> >> drivers/built-in.o: In function `cdrom_sysctl_register':
> >> (.text+0x1577a8): undefined reference to `cdrom_check_media_type'
> >>
> >> Probably caused by commit d01681d1457c ("cdrom: export sysctl code").
> >> This build has CONFIG_SYSCTL=y, CONFIG_BLK_DEV_IDECD=m,
> >> CONFIG_BLK_DEV_SR=m, CONFIG_PARIDE_PCD=m, CONFIG_CDROM_PKTCDVD=m,
> >> CONFIG_GDROM=n.
> >>
> >> I have used the block tree from next-20141110 for today.
> >> --
> >> Cheers,
> >> Stephen Rothwell                    sfr@...b.auug.org.au
> >
> > Hi Stephen,
> >
> > Problem is in Makefile:
> >
> > obj-$(CONFIG_BLK_DEV_SR) += cdrom.o
> > obj-$(CONFIG_PARIDE_PCD) += cdrom.o
> > obj-$(CONFIG_CDROM_PKTCDVD) += cdrom.o
> > +obj-$(CONFIG_SYSCTL) += cdrom_sysctl.o
> >
> > I tried cdrom-$(CONFIG_SYSCTL)  += cdrom_sysctl.o
> > to add sysctl only when cdrom.o is created
> >
> > but now
> >
> > drivers/scsi/sr_mod.ko
> > drivers/ide/ide-cd_mod.ko
> > drivers/ide/ide-cd_mod.ko
> >
> > can't find cdrom.c functions ...
> >
> > Is there another way to do it ?
>
> The problem is, now you can have cdrom/sr modular, but cdrom_sysctl.o is
> linked in. That's just not going to work. Instead of jumping through
> hoops to make this work, leave the section in cdrom.c and hid it behind a
>
> #if defined(CONFIG_SYSCTL)
> ...
> #endif
>
> at the bottom or something.
>
> --
> Jens Axboe
>

Hi Jens,

   It's already the case in current code so I'll drop this patch.
I've got a small question about another one:
(http://marc.info/?l=linux-kernel&m=141565102708591&w=2)

I was looking if there was a reason for calling

init_cdrom_command with 0 length in dvd_do_auth():

   memset(buf, 0, sizeof(buf));
   init_cdrom_command(&cgc, buf, 0, CGC_DATA_READ)
       
This doesn't impact setup_report_key/setup_send_key
calls -as those functions initialize cgc buflen again
depending on type argument- without DVD_INVALIDATE_AGID:
we call setup_report_key(&cgc, ai->lsa.agid, 0x3f);
where type is used for cmd[10]:

   cgc->cmd[10] = type | (agid << 6);

the switch(type) below doesn't have 0x3f case so we
go directly to

   cgc->cmd[9] = cgc->buflen;

I replaced the 2 lines above with

   init_cdrom_command(&cgc, buf, sizeof(buf), CGC_DATA_READ)

(as memset is already done during init_cdrom_command) but that would
change buflen in that case and subsequent cdo->generic_packet
behaviour or am I missing something ?

Regards,
Fabian
--
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/

Powered by blists - more mailing lists