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@xxxxxxxxxxxxxxx on behalf of Christoph Hellwig" <target-devel-owner@xxxxxxxxxxxxxxx on behalf of hch@xxxxxxxxxxxxx> wrote: >On Mon, Dec 07, 2015 at 07:48:59PM -0500, Himanshu Madhani wrote: >> From: Quinn Tran <quinn.tran@xxxxxxxxxx> >> >> 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@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html
<<attachment: winmail.dat>>
