linux-kernel - Re: 4.3+: Atheros ethernet fails after resume from s2ram, due to order 4 allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151128145003.GA4135@amd>
Date:	Sat, 28 Nov 2015 15:50:03 +0100
From:	Pavel Machek <pavel@....cz>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	kernel list <linux-kernel@...r.kernel.org>, jcliburn@...il.com,
	chris.snook@...il.com, netdev@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>, linux-mm@...ck.org,
	nic-devel@...lcomm.com, ronangeles@...il.com, ebiederm@...ssion.com
Subject: Re: 4.3+: Atheros ethernet fails after resume from s2ram, due to
 order 4 allocation

Hi!


> >         /*                                                                      
> >          * real ring DMA buffer                                                 
> >          * each ring/block may need up to 8 bytes for alignment, hence the      
> >          * additional bytes tacked onto the end.                                
> >          */
> >         ring_header->size = size =
> >                 sizeof(struct atl1c_tpd_desc) * tpd_ring->count * 2 +
> >                 sizeof(struct atl1c_rx_free_desc) * rx_desc_count +
> >                 sizeof(struct atl1c_recv_ret_status) * rx_desc_count +
> >                 8 * 4;
> > 
> >         ring_header->desc = pci_alloc_consistent(pdev, ring_header->size,
> >                                 &ring_header->dma);
> 
> Why is pci_alloc_consistent doing an unconditional GFP_ATOMIC
> allocation? atl1_setup_ring_resources already does GFP_KERNEL
> allocation in the same function so this should be sleepable
> context. I think we should either add pci_alloc_consistent_gfp if
> there are no explicit reasons to not do so or you can workaround

There's existing interface "dma_alloc_coherent" which can be used.

I did not yet try with __GFP_REPEAT, but GFP_KERNEL should already be
big improvement.

Let me send a patch..
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/