linux-kernel - Re: [RFC][PATCH 2/9] deadlock prevention core

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: <20060809131942.GY14627@postel.suug.ch>
Date:	Wed, 9 Aug 2006 15:19:42 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	Daniel Phillips <phillips@...gle.com>
Cc:	David Miller <davem@...emloft.net>, a.p.zijlstra@...llo.nl,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [RFC][PATCH 2/9] deadlock prevention core

* Daniel Phillips <phillips@...gle.com> 2006-08-08 22:47
> David Miller wrote:
> >From: Daniel Phillips <phillips@...gle.com>
>  >>Can you please characterize the conditions under which skb->dev changes
> >>after the alloc?  Are there writings on this subtlety?
> >
> >The packet scheduler and classifier can redirect packets to different
> >devices, and can the netfilter layer.
> >
> >The setting of skb->dev is wholly transient and you cannot rely upon
> >it to be the same as when you set it on allocation.
> >
> >Even simple things like the bonding device change skb->dev on every
> >receive.
> 
> Thankyou, this is easily fixed.

It's not that simple, in order to just fix the most obvious case
being packet forwarding when skb->dev changes its meaning from
device the packet is coming from to device the packet will be leaving
on is difficult.

You can't unreserve at that point so you need to keep the original
skb->dev. Since the packet is mostly likely queued before freeing
you will lose the refcnt on the original skb->dev. Keeping a
refcnt just for this memalloc stuff is out of question. Even keeping
the ifindex on a best effort basis is unlikely an option, sk_buff is
way overweight already.
-
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/