[Bug 176951] boot fails unless acpi=off Acer Travelmate X-349

https://bugzilla.kernel.org/show_bug.cgi?id=176951 Max (700...@gmail.com) changed: What|Removed |Added CC||700...@gmail.com --- Comment

Re: [PATCH] Avoid that scsi_exit_rq() triggers a use-after-free

On Tue, May 02, 2017 at 10:43:30AM -0700, Bart Van Assche wrote: > This patch fixes the following KASAN complaint: > > == > BUG: KASAN: use-after-free in scsi_exit_rq+0xf3/0x120 at addr 8802b7fedf00 > Read of size 1 by task

Re: BUG: KASAN: use-after-free in scsi_exit_rq

On Tue, 2017-05-02 at 16:41 +0200, Jan Kara wrote: > So I'm also not aware of any particular breakage this would cause. However > logically the freeing of request mempools really belongs to > blk_release_queue() so it seems a bit dumb to move blk_exit_rl() just > because SCSI stores the fact from

[PATCH] Avoid that scsi_exit_rq() triggers a use-after-free

This patch fixes the following KASAN complaint: == BUG: KASAN: use-after-free in scsi_exit_rq+0xf3/0x120 at addr 8802b7fedf00 Read of size 1 by task rcuos/5/53 CPU: 7 PID: 53 Comm: rcuos/6 Not tainted 4.11.0-rc5+ #13 Hardware

[PATCH v2] ibmvscsis: Do not send aborted task response

The driver is sending a response to the actual scsi op that was aborted by an abort task TM, while LIO is sending a response to the abort task TM. ibmvscsis_tgt does not send the response to the client until release_cmd time. The reason for this was because if we did it at queue_status time, then

[PATCH] scsi_lib: Add #include

This patch avoids that when building with W=1 the compiler complains that __scsi_init_queue() has not been declared. See also commit d48777a633d6 ("scsi: remove __scsi_alloc_queue"). Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes

[PATCH v6 4/5] Introduce scsi_start_queue()

This patch does not change any functionality. Signed-off-by: Bart Van Assche Cc: Israel Rukshin Cc: Max Gurtovoy Cc: Hannes Reinecke Cc: Benjamin Block --- drivers/scsi/scsi_lib.c

[PATCH v6 2/5] Create two versions of scsi_internal_device_unblock()

This will make it easier to serialize SCSI device state changes through a mutex. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Johannes Thumshirn Cc: Sreekanth Reddy

[PATCH v6 5/5] Make __scsi_remove_device go straight from BLOCKED to DEL

If a device is blocked, make __scsi_remove_device() cause it to transition to the DEL state. This means that all the commands issued in .shutdown() will error in the mid-layer, thus making the removal proceed without being stopped. This patch is a slightly modified version of a patch from James

[PATCH v6 3/5] Protect SCSI device state changes with a mutex

Enable this mechanism for all scsi_target_*block() callers but not for the scsi_internal_device_unblock() calls from the mpt3sas driver because that driver can call scsi_internal_device_unblock() from atomic context. Signed-off-by: Bart Van Assche Cc: Christoph

[PATCH v6 1/5] Split scsi_internal_device_block()

Instead of passing a "wait" argument to scsi_internal_device_block(), split this function into a function that waits and a function that doesn't wait. This will make it easier to serialize SCSI device state changes through a mutex. Signed-off-by: Bart Van Assche Cc:

[PATCH v6 0/5] Avoid that __scsi_remove_device() hangs

__scsi_remove_device() hangs if it is waiting for the SYNCHRONIZE CACHE command submitted by the sd driver to finish if the block layer queue is stopped and does not get restarted. This patch series avoids that that hang occurs. Changes compared to v5: - Reworked the approach. Instead of

Re: [PATCH 25/27] block: remove the discard_zeroes_data flag

On Mon, 2017-05-01 at 20:45 +, Bart Van Assche wrote: > On Wed, 2017-04-05 at 19:21 +0200, Christoph Hellwig wrote: > > Now that we use the proper REQ_OP_WRITE_ZEROES operation everywhere we can > > kill this hack. > > > > Signed-off-by: Christoph Hellwig > > Reviewed-by: Martin

Re: [PATCH 25/27] block: remove the discard_zeroes_data flag

On Tue, May 02, 2017 at 12:16:13AM -0700, Nicholas A. Bellinger wrote: > Or, another options is use bdev_write_zeroes_sectors() to determine when > dev_attrib->unmap_zeroes_data should be set. Yes, that in combination with your patch to use bdev_write_zeroes_sectors for zeroing from write same

[PATCH, RFC] MAINTAINERS: update OSD entries

The open-osd domain doesn't exist anymore, and mails to the list lead to really annoying bounced that repeat every day. Also the primarydata address for Benny bounces, and while I have a new one for him he doesn't seem to be maintaining the OSD code any more. Which beggs the question: should we

[PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories

From: Xiubo Li For the "struct tcmu_cmd_entry" in cmd area, the minimum size will be sizeof(struct tcmu_cmd_entry) == 112 Bytes. And it could fill about (sizeof(struct rsp) - sizeof(struct req)) / sizeof(struct iovec) == 68 / 16 ~= 4 data regions(iov[4]) by default.

答复: [PATCH v6 0/2] tcmu: Dynamic growing data area support

> > Xiubo Li (2): > > tcmu: Add dynamic growing data area feature support > > tcmu: Add global data block pool support > > > > drivers/target/target_core_user.c | 598 > > ++ > > 1 file changed, 469 insertions(+), 129 deletions(-) > > > > So based upon the

Re: [PATCH, RFC] MAINTAINERS: update OSD entries

On Tue, 2017-05-02 at 09:57 +0200, Christoph Hellwig wrote: > The open-osd domain doesn't exist anymore, and mails to the list lead > to really annoying bounced that repeat every day. > > Also the primarydata address for Benny bounces, and while I have a new > one for him he doesn't seem to be

Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories

On 05/02/2017 02:54 AM, lixi...@cmss.chinamobile.com wrote: > From: Xiubo Li > > For the "struct tcmu_cmd_entry" in cmd area, the minimum size > will be sizeof(struct tcmu_cmd_entry) == 112 Bytes. And it could > fill about (sizeof(struct rsp) - sizeof(struct req)) /

Re: [PATCH 25/27] block: remove the discard_zeroes_data flag

On Tue, 2017-05-02 at 09:23 +0200, h...@lst.de wrote: > On Tue, May 02, 2017 at 12:16:13AM -0700, Nicholas A. Bellinger wrote: > > Or, another options is use bdev_write_zeroes_sectors() to determine when > > dev_attrib->unmap_zeroes_data should be set. > > Yes, that in combination with your patch

Re: [PATCH v2] ibmvscsis: Do not send aborted task response

On Tue, 2017-05-02 at 13:54 -0500, Bryant G. Ly wrote: > The driver is sending a response to the actual scsi op that was > aborted by an abort task TM, while LIO is sending a response to > the abort task TM. > > ibmvscsis_tgt does not send the response to the client until > release_cmd time. The

Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories

On Tue, 2017-05-02 at 21:06 -0500, Mike Christie wrote: > On 05/02/2017 02:54 AM, lixi...@cmss.chinamobile.com wrote: > > From: Xiubo Li > > > > For the "struct tcmu_cmd_entry" in cmd area, the minimum size > > will be sizeof(struct tcmu_cmd_entry) == 112 Bytes. And

Re: [PATCH 1/3] scsi_dh_alua: Do not modify the interval value for retries

On 04/28/2017 08:35 PM, Bart Van Assche wrote: > On Fri, 2017-04-28 at 15:06 +0200, Martin Wilck wrote: >> @@ -886,7 +883,7 @@ static bool alua_rtpg_queue(struct alua_port_group *pg, >> force = true; >> } >> if (pg->rtpg_sdev == NULL) { >> -pg->interval = 0; >> +

Re: [PATCH 25/27] block: remove the discard_zeroes_data flag

On Mon, 2017-05-01 at 23:43 -0700, Nicholas A. Bellinger wrote: > On Mon, 2017-05-01 at 20:45 +, Bart Van Assche wrote: > > On Wed, 2017-04-05 at 19:21 +0200, Christoph Hellwig wrote: > > > Now that we use the proper REQ_OP_WRITE_ZEROES operation everywhere we can > > > kill this hack. > > >

Re: BUG: KASAN: use-after-free in scsi_exit_rq

On Fri 28-04-17 17:46:47, Tejun Heo wrote: > On Fri, Apr 21, 2017 at 09:49:17PM +, Bart Van Assche wrote: > > On Thu, 2017-04-20 at 15:18 -0600, Scott Bauer wrote: > > > [ 642.638860] BUG: KASAN: use-after-free in scsi_exit_rq+0xf3/0x120 at > > > addr 8802b7fedf00 > > > [ 642.639362]

I NEED YOUR URGENT HELP AND CORPERATION

Dear Friend, I am contacting you on a business deal of $9,500,000.00 Million United States Dollars, ready for transfer into your own personal account and if we make this claim, we will share it on the ratio of 50% / 50% basis, I would like to assure you that it be 100% risk free and it will