NAK: [SRU][F][PATCH 1/1] s390/qeth: use memory reserves to back RX buffers
Krzysztof Kozlowski
krzysztof.kozlowski at canonical.com
Fri Feb 4 09:29:21 UTC 2022
On 04/02/2022 07:47, frank.heimes at canonical.com wrote:
> From: Julian Wiedmann <jwi at linux.ibm.com>
>
> BugLink: https://bugs.launchpad.net/bugs/1959529
>
> Use dev_alloc_page() for backing the RX buffers with pages. This way we
> pick up __GFP_MEMALLOC.
>
> Signed-off-by: Julian Wiedmann <jwi at linux.ibm.com>
> Signed-off-by: David S. Miller <davem at davemloft.net>
> (backported from commit 714c9108851743bb718fbc1bfb81290f12a53854)
> Signed-off-by: Alexandra Winter <wintera at linux.ibm.com>
> Signed-off-by: Frank Heimes <frank.heimes at canonical.com>
> ---
> drivers/s390/net/qeth_core_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
> index ec8c7a640d9e..61372e5c279b 100644
> --- a/drivers/s390/net/qeth_core_main.c
> +++ b/drivers/s390/net/qeth_core_main.c
> @@ -227,7 +227,7 @@ static int qeth_alloc_buffer_pool(struct qeth_card *card)
> return -ENOMEM;
> }
> for (j = 0; j < QETH_MAX_BUFFER_ELEMENTS(card); ++j) {
> - ptr = (void *) __get_free_page(GFP_KERNEL);
> + ptr = (void *) __dev_alloc_page(GFP_KERNEL);
This does not look correct. New API returns "struct page*", previous
returns mapped page address. These are not the same.
Either we need to backport f81649dfa5343eef7e579eb6f8dd8bd6d300ec31
first or a page_address dance like:
struct page *page = __dev_alloc_page(GFP_KERNEL);
if (!page)
// handle -ENOMEM
ptr = page_address(page);
> if (!ptr) {
> while (j > 0)
> free_page((unsigned long)
> @@ -2612,7 +2612,7 @@ static struct qeth_buffer_pool_entry *qeth_find_free_buffer_pool_entry(
> struct qeth_buffer_pool_entry, list);
> for (i = 0; i < QETH_MAX_BUFFER_ELEMENTS(card); ++i) {
> if (page_count(virt_to_page(entry->elements[i])) > 1) {
> - page = alloc_page(GFP_ATOMIC);
> + page = dev_alloc_page();
> if (!page) {
> return NULL;
> } else {
Best regards,
Krzysztof
More information about the kernel-team
mailing list