study

Reception of unsolicited arp

2.4에서는 unsolicited ARP reply 수신 여부를 커널 빌드 옵션으로 결정했지만 2.6에서는 proc의 arp_accept 값으로 선택할 수 있다.

 

kernel 2.4

#ifdef CONFIG_IP_ACCEPT_UNSOLICITED_ARP
    /* Unsolicited ARP is not accepted by default.
       It is possible, that this option should be enabled for some
       devices (strip is candidate)
     */
    if (n == NULL && 
        arp->ar_op == htons(ARPOP_REPLY) &&
        inet_addr_type(sip) == RTN_UNICAST)
        n = __neigh_lookup(&arp_tbl, &sip, dev, -1);
#endif

kernel 2.6

    if (ipv4_devconf.arp_accept) {
        /* Unsolicited ARP is not accepted by default.
           It is possible, that this option should be enabled for some
           devices (strip is candidate)
         */
        if (n == NULL && 
            arp->ar_op == htons(ARPOP_REPLY) &&
            inet_addr_type(sip VRF_CALL_ARG(dev->vrf)) == RTN_UNICAST)
            n = __neigh_lookup(&arp_tbl, &sip, dev, 1);
    }
study

ioctl(), the big kernel lock, and 32-bit compatibility [LWN.net]

ioctl(), the big kernel lock, and 32-bit compatibility [LWN.net].

예전에 구현된 ioctl 자체가 BKL(Big Kernel Lock, lock_kernel())을 걸기 때문에 만일 실행되는 ioctl handler가 시간을 많이 소요하면 전체 프로세스들이 커널을 이용하지 못한다는 의미.

Single processor 환경에서는 kernel context로 들어간 순간 어차피 동작할 수 있는 user process가 없으므로 의미가 없지만, multi-processor에서는 상황이 다르다.

관련된 내용 : http://unix.stackexchange.com/questions/4711/what-is-the-difference-between-ioctl-unlocked-ioctl-and-compat-ioctl

좀더 자세히 보면 fs의 method중 ioctl이 삭제되고 unlocked_ioctl로 대체되었다. 그리고 application에서 ioctl을 호출하면 해당 fs의 unlocked_ioctl을 호출한다.

static long vfs_ioctl(struct file *filp, unsigned int cmd,
              unsigned long arg)
{
    int error = -ENOTTY;

    if (!filp->f_op || !filp->f_op->unlocked_ioctl)
        goto out;

    error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
    if (error == -ENOIOCTLCMD)
        error = -EINVAL;
 out:
    return error;
}

참고 : http://forum.falinux.com/zbxe/?document_srl=553645