| 240 | } |
| 241 | |
| 242 | void |
| 243 | ip_fillid(struct ip *ip) |
| 244 | { |
| 245 | |
| 246 | /* |
| 247 | * Per RFC6864 Section 4 |
| 248 | * |
| 249 | * o Atomic datagrams: (DF==1) && (MF==0) && (frag_offset==0) |
| 250 | * o Non-atomic datagrams: (DF==0) || (MF==1) || (frag_offset>0) |
| 251 | */ |
| 252 | if (V_ip_rfc6864 && (ip->ip_off & htons(IP_DF)) == htons(IP_DF)) |
| 253 | ip->ip_id = 0; |
| 254 | else if (V_ip_do_randomid) |
| 255 | ip->ip_id = ip_randomid(); |
| 256 | else { |
| 257 | counter_u64_add(V_ip_id, 1); |
| 258 | /* |
| 259 | * There are two issues about this trick, to be kept in mind. |
| 260 | * 1) We can migrate between counter_u64_add() and next |
| 261 | * line, and grab counter from other CPU, resulting in too |
| 262 | * quick ID reuse. This is tolerable in our particular case, |
| 263 | * since probability of such event is much lower then reuse |
| 264 | * of ID due to legitimate overflow, that at modern Internet |
| 265 | * speeds happens all the time. |
| 266 | * 2) We are relying on the fact that counter(9) is based on |
| 267 | * UMA_ZONE_PCPU uma(9) zone. We also take only last |
| 268 | * sixteen bits of a counter, so we don't care about the |
| 269 | * fact that machines with 32-bit word update their counters |
| 270 | * not atomically. |
| 271 | */ |
| 272 | ip->ip_id = htons((*(uint64_t *)zpcpu_get(V_ip_id)) & 0xffff); |
| 273 | } |
| 274 | } |
| 275 | |
| 276 | static void |
| 277 | ipid_sysinit(void) |
no test coverage detected