linux-kernel - Re: [PATCH 0/4] w1: refcnt fix, skip non-error send, docs

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]

Date:	Wed, 05 Feb 2014 03:48:45 +0400
From:	zbr@...emap.net
To:	David Fries <david@...es.net>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] w1: refcnt fix, skip non-error send, docs

Hi

04.02.2014, 09:51, "David Fries" <david@...es.net>:
> Help me understand what the protocol is supposed to be.  Assuming
> there aren't any errors, is there supposed to be a
> w1_netlink_send_error generated reply per netlink packet (cn_msg), per
> w1_netlink_msg, or per w1_netlink_cmd?

reply should be sent per cmd to specify each command status
If there is no cmd in request or we didn't get to it (like failed to reset device), we should send error.

Depending on how w1-msg + (optional) w1-cmd are packed, client can detect what exact error happend

> What about the cn_msg seq and ack values?  I assume the kernel
> response should carry the same seq number as the request, but what
> should the ack be set to?

reply ack is seq + 1
seq is the same to highlight request it belongs to
--
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/