linux-kernel - Re: [PATCH RESEND 2/3 v2.6.39-rc7] block: make disk_block_events() properly wait for work cancellation

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 May 2011 12:26:41 +0200
From:	Jens Axboe <axboe@...nel.dk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Tejun Heo <tj@...nel.org>, Sitsofe Wheeler <sitsofe@...oo.com>,
	Borislav Petkov <bp@...en8.de>, Meelis Roos <mroos@...ux.ee>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND 2/3 v2.6.39-rc7] block: make disk_block_events()
  properly wait for work cancellation

On 2011-05-18 11:46, Linus Torvalds wrote:
> On Tue, May 17, 2011 at 10:07 PM, Tejun Heo <tj@...nel.org> wrote:
>>
>>> Just make the semaphore protect the count - and you're done.
>>
>> Yeah, with that gone, we don't even need the open-coding inside
>> disk_check_events().  It can simply call syncing block and unblock.
>> But, do you want that in -rc7?  Unnecessarily complicated as the
>> current code may be, converting the lock to mutex is a larger change
>> than adding an outer mutex and I think it would be better to do that
>> during the next cycle.
> 
> Quite frankly. right now I think I need to just release 2.6.39, and
> then for 2.6.40 merge the trivial
> 
>   mutex_lock(&ev->mutex);
>   if (!ev->block++)
>     cancel_delayed_work_sync(&ev->dwork);
>   mutex_unlock(&ev->mutex);
> 
> with a cc: stable for backporting.

With these changes pushed to 2.6.40, I have the following sitting queued
up for 2.6.39, of which at least the performance regression and
blk-throttle fix really should go in. I'll let Tejun voice in on his
three changes. I would have pushed this a few days ago, but this thread
had it postponed a bit.

  git://git.kernel.dk/linux-2.6-block.git for-linus

Jens Axboe (1):
      scsi: remove performance regression due to async queue run

Shaohua Li (1):
      block: don't delay blk_run_queue_async

Tejun Heo (3):
      block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe drivers
      cdrom: always check_disk_change() on open
      block: rescan partitions on invalidated devices on -ENOMEDIA too

Vivek Goyal (1):
      blk-throttle: Use task_subsys_state() to determine a task's blkio_cgroup

 block/blk-cgroup.c              |    7 +++++++
 block/blk-cgroup.h              |    3 +++
 block/blk-core.c                |    4 +++-
 block/blk-throttle.c            |    9 ++++-----
 block/cfq-iosched.c             |   11 +++++------
 drivers/block/DAC960.c          |    1 -
 drivers/block/amiflop.c         |    1 -
 drivers/block/ataflop.c         |    1 -
 drivers/block/floppy.c          |    1 -
 drivers/block/paride/pcd.c      |    1 -
 drivers/block/paride/pd.c       |    1 -
 drivers/block/paride/pf.c       |    1 -
 drivers/block/swim.c            |    1 -
 drivers/block/swim3.c           |    1 -
 drivers/block/ub.c              |    1 -
 drivers/block/xsysace.c         |    1 -
 drivers/cdrom/cdrom.c           |    6 +++---
 drivers/cdrom/gdrom.c           |    1 -
 drivers/cdrom/viocd.c           |    1 -
 drivers/message/i2o/i2o_block.c |    1 -
 drivers/s390/char/tape_block.c  |    1 -
 drivers/scsi/scsi_lib.c         |   20 ++++++++++++++++----
 drivers/scsi/scsi_scan.c        |    2 ++
 fs/block_dev.c                  |   27 ++++++++++++++++++---------
 include/scsi/scsi_device.h      |    1 +
 25 files changed, 62 insertions(+), 43 deletions(-)

-- 
Jens Axboe

--
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/