Okay... I can't help but think I made a mistake somewhere in the bisecting process, but it seems to have isolated fd4b5fa6e3487d15ede746f92601af008b2abbc0 as the bad commit
$ git bisect log
# bad: [6d4f0a79e5a307b6fd3ee3cc5bbb2fcb701b09db] UBUNTU: Ubuntu-4.4.0-57.78
# good: [40a98f0e91bcc062babd017732cbf7cb20cf39fd] UBUNTU: Ubuntu-4.4.0-51.72
git bisect start 'Ubuntu-4.4.0-57.78' 'Ubuntu-4.4.0-51.72'
# bad: [cd29d2303e86529c089b1c292480c05e7a24bd16] drm/i915: Respect alternate_ddc_pin for all DDI ports
git bisect bad cd29d2303e86529c089b1c292480c05e7a24bd16
# bad: [617dec606ff9e43e64a06daef83e17da0035340a] drm/exynos: fix error handling in exynos_drm_subdrv_open
git bisect bad 617dec606ff9e43e64a06daef83e17da0035340a
# bad: [0dbd2050197ea4dd59f8957b72981cb7d2cfab1c] usb: gadget: function: u_ether: don't starve tx request queue
git bisect bad 0dbd2050197ea4dd59f8957b72981cb7d2cfab1c
# bad: [f3f9de1bd9a63b633946226ba23392ad44e2badf] i2c: core: fix NULL pointer dereference under race condition
git bisect bad f3f9de1bd9a63b633946226ba23392ad44e2badf
# good: [a0678a6643bf688bccce3c298a4a110af10988fc] ipv6: correctly add local routes when lo goes up
git bisect good a0678a6643bf688bccce3c298a4a110af10988fc
# good: [a0ae41d8ee0549161174a39d60f7316b67a87cae] Bluetooth: btusb: Add support for 0cf3:e009
git bisect good a0ae41d8ee0549161174a39d60f7316b67a87cae
# good: [d5d9494d2092a7e571dee635ca254075912355c1] thinkpad_acpi: Add support for HKEY version 0x200
git bisect good d5d9494d2092a7e571dee635ca254075912355c1
# bad: [a6e674fa25854a7dafc59555d508855ea8fe3eaa] i2c: xgene: Avoid dma_buffer overrun
git bisect bad a6e674fa25854a7dafc59555d508855ea8fe3eaa
# bad: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts
git bisect bad fd4b5fa6e3487d15ede746f92601af008b2abbc0
# first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts
From a layman perspective, it doesn't seem like that could possibly cause the bug.
I guess one quick way forward, rather than repeat the whole bisecting process, is to completely reset the repository, bring it up to date, verify the bug still exists, and then revert this specific commit and see if the bug goes away.
Okay... I can't help but think I made a mistake somewhere in the bisecting process, but it seems to have isolated fd4b5fa6e3487d1 5ede746f92601af 008b2abbc0 as the bad commit
$ git bisect log b6fd3ee3cc5bbb2 fcb701b09db] UBUNTU: Ubuntu-4.4.0-57.78 62babd017732cbf 7cb20cf39fd] UBUNTU: Ubuntu-4.4.0-51.72 4.4.0-57. 78' 'Ubuntu- 4.4.0-51. 72' 9c089b1c292480c 05e7a24bd16] drm/i915: Respect alternate_ddc_pin for all DDI ports c089b1c292480c0 5e7a24bd16 3e64a06daef83e1 7da0035340a] drm/exynos: fix error handling in exynos_ drm_subdrv_ open e64a06daef83e17 da0035340a dd59f8957b72981 cb7d2cfab1c] usb: gadget: function: u_ether: don't starve tx request queue d59f8957b72981c b7d2cfab1c 633946226ba2339 2ad44e2badf] i2c: core: fix NULL pointer dereference under race condition 33946226ba23392 ad44e2badf 8bccce3c298a4a1 10af10988fc] ipv6: correctly add local routes when lo goes up bccce3c298a4a11 0af10988fc 161174a39d60f73 16b67a87cae] Bluetooth: btusb: Add support for 0cf3:e009 61174a39d60f731 6b67a87cae e571dee635ca254 075912355c1] thinkpad_acpi: Add support for HKEY version 0x200 571dee635ca2540 75912355c1 7dafc59555d5088 55ea8fe3eaa] i2c: xgene: Avoid dma_buffer overrun dafc59555d50885 5ea8fe3eaa 15ede746f92601a f008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts 5ede746f92601af 008b2abbc0 15ede746f92601a f008b2abbc0] mnt: Add a per mount namespace limit on the number of mounts
# bad: [6d4f0a79e5a307
# good: [40a98f0e91bcc0
git bisect start 'Ubuntu-
# bad: [cd29d2303e8652
git bisect bad cd29d2303e86529
# bad: [617dec606ff9e4
git bisect bad 617dec606ff9e43
# bad: [0dbd2050197ea4
git bisect bad 0dbd2050197ea4d
# bad: [f3f9de1bd9a63b
git bisect bad f3f9de1bd9a63b6
# good: [a0678a6643bf68
git bisect good a0678a6643bf688
# good: [a0ae41d8ee0549
git bisect good a0ae41d8ee05491
# good: [d5d9494d2092a7
git bisect good d5d9494d2092a7e
# bad: [a6e674fa25854a
git bisect bad a6e674fa25854a7
# bad: [fd4b5fa6e3487d
git bisect bad fd4b5fa6e3487d1
# first bad commit: [fd4b5fa6e3487d
From a layman perspective, it doesn't seem like that could possibly cause the bug.
I guess one quick way forward, rather than repeat the whole bisecting process, is to completely reset the repository, bring it up to date, verify the bug still exists, and then revert this specific commit and see if the bug goes away.