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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 8 Dec 2020 12:55:26 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        Bart Van Assche <bvanassche@....org>,
        Can Guo <cang@...eaurora.org>, Christoph Hellwig <hch@....de>,
        Hannes Reinecke <hare@...e.de>, Jens Axboe <axboe@...nel.dk>,
        Stanley Chu <stanley.chu@...iatek.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the scsi-mkp tree

On Tue, Dec 08, 2020 at 08:38:59PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 8 Dec 2020 20:28:53 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > Hi all,
> > 
> > After merging the scsi-mkp tree, today's linux-next build (sparc64
> > defconfig) failed like this:
> > 
> > drivers/mtd/nand/raw/intel-nand-controller.c:17:10: fatal error: linux/mtd/nand_ecc.h: No such file or directory
> >    17 | #include <linux/mtd/nand_ecc.h>
> >       |          ^~~~~~~~~~~~~~~~~~~~~~
> 
> Clearly, it did not fail like that :-)
> 
> block/blk-core.c: In function 'blk_queue_enter':
> block/blk-core.c:443:18: error: 'struct request_queue' has no member named 'rpm_status'; did you mean 'stats'?
>     if ((pm && q->rpm_status != RPM_SUSPENDED) ||
>                   ^~~~~~~~~~
>                   stats
> 
> > Caused by commit
> > 
> >   81a395cdc176 ("scsi: block: Do not accept any requests while suspended")
> > 
> > # CONFIG_PM is not set
> > 
> > I have applied the following patch:
> > 
> > From: Stephen Rothwell <sfr@...b.auug.org.au>
> > Date: Tue, 8 Dec 2020 20:12:33 +1100
> > Subject: [PATCH] scsi: block: fix for "scsi: block: Do not accept any requests while suspended"
> > 
> > Fixes: 81a395cdc176 ("scsi: block: Do not accept any requests while suspended")
> > Signed-off-by: Stephen Rothwell <sfr@...b.auug.org.au>
> > ---
> >  block/blk-core.c | 18 ++++++++++++++----
> >  1 file changed, 14 insertions(+), 4 deletions(-)
> > 
> > diff --git a/block/blk-core.c b/block/blk-core.c
> > index a71a5c9429d6..9c9aec1382be 100644
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -421,6 +421,18 @@ void blk_cleanup_queue(struct request_queue *q)
> >  }
> >  EXPORT_SYMBOL(blk_cleanup_queue);
> >  
> > +#ifdef CONFIG_PM
> > +static bool rq_suspended(struct request_queue *q)
> > +{
> > +	return q->rpm_status == RPM_SUSPENDED;
> > +}
> > +#else
> > +static bool rq_suspended(struct request_queue *q)
> > +{
> > +	return false;
> > +}
> > +#endif
> > +
> >  /**
> >   * blk_queue_enter() - try to increase q->q_usage_counter
> >   * @q: request queue pointer
> > @@ -440,12 +452,10 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
> >  			 * responsible for ensuring that that counter is
> >  			 * globally visible before the queue is unfrozen.
> >  			 */
> > -			if ((pm && q->rpm_status != RPM_SUSPENDED) ||
> > -			    !blk_queue_pm_only(q)) {
> > +			if ((pm && !rq_suspended(q)) || !blk_queue_pm_only(q))
> >  				success = true;
> > -			} else {
> > +			else
> >  				percpu_ref_put(&q->q_usage_counter);
> > -			}
> >  		}
> >  		rcu_read_unlock();

Yes, that certainly is the proper fix.  It's all to easy to miss these 
issues that depend on your kernel configuration.

Bart, can you fold it into a new version of the patch?

Alan Stern

Powered by blists - more mailing lists