Greg Kroah-Hartman
598cf27219
Link: https://lore.kernel.org/r/20260217200002.683975158@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
18 lines
798 B
ReStructuredText
18 lines
798 B
ReStructuredText
TODO
|
|
====
|
|
|
|
There is a potential for deadlock when allocating a struct sk_buff for
|
|
data that needs to be written out to aoe storage. If the data is
|
|
being written from a dirty page in order to free that page, and if
|
|
there are no other pages available, then deadlock may occur when a
|
|
free page is needed for the sk_buff allocation. This situation has
|
|
not been observed, but it would be nice to eliminate any potential for
|
|
deadlock under memory pressure.
|
|
|
|
Because ATA over Ethernet is not fragmented by the kernel's IP code,
|
|
the destructor member of the struct sk_buff is available to the aoe
|
|
driver. By using a mempool for allocating all but the first few
|
|
sk_buffs, and by registering a destructor, we should be able to
|
|
efficiently allocate sk_buffs without introducing any potential for
|
|
deadlock.
|