obj-$(CONFIG_FB_INTEL) += intelfb.o intelfb-y := intelfbdrv.o intelfbhw.o intelfb-$(CONFIG_FB_INTEL_I2C) += intelfb_i2c.o intelfb-objs := $(intelfb-y) ccflags-$(CONFIG_FB_INTEL_DEBUG) := -DDEBUG -DREGDUMP l='alternate' title='Atom feed' href='https://git.distanz.ch/cgit.cgi/linux/net-next.git/atom/?h=master' type='application/atom+xml'/>
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMahesh Bandewar <maheshb@google.com>2017-01-09 15:05:54 -0800
committerDavid S. Miller <davem@davemloft.net>2017-01-10 20:47:12 -0500
commitda36e13cf653541e385a8d2ec2637fff6ea3461a (patch)
tree3d86b8c8337e679806f77b875ee6564ebf6712dc
parentde28c99d71d91251713b67c545fa05b2b5e0d232 (diff)
ipvlan: improvise dev_id generation logic in IPvlan
The patch 009146d117b ("ipvlan: assign unique dev-id for each slave device.") used ida_simple_get() to generate dev_ids assigned to the slave devices. However (Eric has pointed out that) there is a shortcoming with that approach as it always uses the first available ID. This becomes a problem when a slave gets deleted and a new slave gets added. The ID gets reassigned causing the new slave to get the same link-local address. This side-effect is undesirable. This patch adds a per-port variable that keeps track of the IDs assigned and used as the stat-base for the IDR api. This base will be wrapped around when it reaches the MAX (0xFFFE) value possibly on a busy system where slaves are added and deleted routinely. Fixes: 009146d117b ("ipvlan: assign unique dev-id for each slave device.") Signed-off-by: Mahesh Bandewar <maheshb@google.com> CC: Eric Dumazet <edumazet@google.com> CC: David Miller <davem@davemloft.org> Signed-off-by: David S. Miller <davem@davemloft.net>