Christoph, Understood. I was not sure which way the community is swinging. For what itıs worth, this fix was required to stabilize one of our customer environment in the older kernel. Regards, Quinn Tran On 12/7/15, 6:48 PM, "target-devel-owner@vger.kernel.org on behalf of Christoph Hellwig" wrote: >On Mon, Dec 07, 2015 at 07:48:59PM -0500, Himanshu Madhani wrote: >> From: Quinn Tran >> >> During LUN/Target reset, the TMR code attempt to intercept >> cmds and try to aborted them. Current code assume cmds are >> always intercepted at the back end device. The cleanup code >> would issue a "queue_status() & check_stop_free()" to terminate >> the command. However, when a cmd is intercepted at the front >> end/Fabric layer, current code introduce premature free or >> cause Fabric to double free. >> >> When command is intercepted at Fabric layer, it means a >> check_stop_free(cmd_kref--) has been called. The extra >> check_stop_free in the Lun Reset cleanup code causes early >> free. When a cmd in the Fabric layer is completed, the normal >> free code adds another another free which introduce a double free. >> >> To fix the issue: >> - add a new flag/CMD_T_SENT_STATUS to track command that have >> made it down to fabric layer after back end good/bad completion. >> - if cmd reach Fabric Layer at Lun Reset time, add an extra >> cmd_kref count to prevent premature free. > >This seems lke something solved by Bart's abort rewrite in a much nicer >way. All this special casing based on magic flags isn't maintainable >in the long run. >-- >To unsubscribe from this list: send the line "unsubscribe target-devel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html