Hung processes stuck in D state after starting a second audit consumer

Greetings audit mailing list, I've got an AWS instance running an Amazon Linux kernel, 4.9.77-31.58.amzn1.x86_64 with the base OS being CentOS 6. The instance had one program with the audit handle (Proprietary closed source software, Lacework agent). I installed and started OSQuery which attempted to acquire the audit handle. I'm unsure if osquery was successful or not, because I was unable to ssh in to the server to investigate. I ended up having to restart the instance. Almost immediately after starting osquery, sshd got stuck in D state. syslog has a hung task warning and backtrace that provides some information: Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.724101] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.727856] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.731856] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736283] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736287] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736290] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736292] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736295] Call Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736302] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736304] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736306] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736308] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736311] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736313] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736316] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736319] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736320] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736323] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736324] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736327] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736330] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736332] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736333] Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736335] I've been doing some reading (ex. https://www.redhat.com/archives/linux-audit/2016-February/msg00025.html ) and my understanding is that osquery should have been able to acquire the audit handle, trampling lacework's ("Last one wins"), but I don't have access to the Lacework code to know how it might handle that situation (I'm engaging their support separately). I also noticed the patch set for 4.17 seemed to include some changes around the code path in the backtrace. I'm trying to understand this behavior and determine if it's a bug, if said bug has already been fixed by a patch between 4.9.77 and 4.17, or that this issue is a lack of my understanding of the behavior of the audit system. It is surprising to me that an audit system related issue would result in sshd getting stuck in D state. Several other processes on the system continued running without incident. Processed launched out of cron also got stuck in D state. I would be grateful for some expert insight. If this isn't a bug and is a misunderstanding on my part, is there any way to configure the audit system such that an issue won't result in processes getting stuck in D state? Thanks, Preston Bennes