linux-decnet-user — Discussion for users of DECnet on Linux

Re: [Linux-decnet-user] get rid of the address_space override in setsockopt v2

[David M. <da...@da...>]

From: Christoph Hellwig <hc...@ls...>
Date: Sun, 26 Jul 2020 09:03:11 +0200

> On Fri, Jul 24, 2020 at 03:43:42PM -0700, David Miller wrote:
>> > Changes since v1:
>> >  - check that users don't pass in kernel addresses
>> >  - more bpfilter cleanups
>> >  - cosmetic mptcp tweak
>> 
>> Series applied to net-next, I'm build testing and will push this out when
>> that is done.
> 
> The buildbot found one warning with the isdn debug code after a few
> days, here is what I think is the best fix:

I already fixed this in net-next.

Re: [Linux-decnet-user] get rid of the address_space override in setsockopt v2

[David M. <da...@da...>]

From: Christoph Hellwig <hc...@ls...>
Date: Thu, 23 Jul 2020 08:08:42 +0200

> setsockopt is the last place in architecture-independ code that still
> uses set_fs to force the uaccess routines to operate on kernel pointers.
> 
> This series adds a new sockptr_t type that can contained either a kernel
> or user pointer, and which has accessors that do the right thing, and
> then uses it for setsockopt, starting by refactoring some low-level
> helpers and moving them over to it before finally doing the main
> setsockopt method.
> 
> Note that apparently the eBPF selftests do not even cover this path, so
> the series has been tested with a testing patch that always copies the
> data first and passes a kernel pointer.  This is something that works for
> most common sockopts (and is something that the ePBF support relies on),
> but unfortunately in various corner cases we either don't use the passed
> in length, or in one case actually copy data back from setsockopt, or in
> case of bpfilter straight out do not work with kernel pointers at all.
> 
> Against net-next/master.
> 
> Changes since v1:
>  - check that users don't pass in kernel addresses
>  - more bpfilter cleanups
>  - cosmetic mptcp tweak

Series applied to net-next, I'm build testing and will push this out when
that is done.

Thanks.

Re: [Linux-decnet-user] [PATCH 24/24] net: pass a sockptr_t into ->setsockopt

[David M. <da...@da...>]

From: Stefan Schmidt <st...@da...>
Date: Mon, 20 Jul 2020 16:19:38 +0200

> For the ieee802154 part:
> 
> Acked-by: Stefan Schmidt <st...@da...>

Please do not quote an entire patch just to add an ACK, trim it just
to the commit message, or even less.

Thank you.

Re: [Linux-decnet-user] [PATCH] net: decnet: af_decnet: Simplify goto loop.

[David M. <da...@da...>]

From: Suraj Upadhyay <usu...@gm...>
Date: Fri, 17 Jul 2020 00:46:45 +0530

> Replace goto loop with while loop.
> 
> Signed-off-by: Suraj Upadhyay <usu...@gm...>

Applied to net-next.

Re: [Linux-decnet-user] [PATCH] [net/decnet] dn_route_rcv: remove redundant dev null check

[David M. <da...@da...>]

From: Gaurav Singh <gau...@gm...>
Date: Mon, 22 Jun 2020 23:41:19 -0400

> dev cannot be NULL here since its already being accessed
> before. Remove the redundant null check.
> 
> Signed-off-by: Gaurav Singh <gau...@gm...>

Applied.

Re: [Linux-decnet-user] [PATCH] Documentation: decnet: remove reference to CONFIG_DECNET_ROUTE_FWMARK

[David M. <da...@da...>]

From: Eduardo Marcelo Serrat <ems...@ho...>
Date: Thu, 8 Aug 2019 11:44:14 +0000

> Sorry for using the list for this purpose but we are looking for
> senior engineers with knowledge in OpenVMS/ Tru64 Unix, Solaris,
> HP-UX and of course Linux and familiar with virtualization
> technologies, specially cross platform emulators. We need to fill
> support engineer roles. If anybody interested for positions in the
> US / Europe please send me an email.

Please do not ever use the vger.kernel.org mailing lists for this kind
of solicitation.

It is completely inappropriate.

Re: [Linux-decnet-user] [PATCH] Documentation: decnet: remove reference to CONFIG_DECNET_ROUTE_FWMARK

[Eduardo M. S. <ems...@ho...>]

Hi all,

Sorry for using the list for this purpose but we are looking for senior engineers with knowledge in OpenVMS/ Tru64 Unix, Solaris, HP-UX and of course Linux and familiar with virtualization technologies, specially cross platform emulators. We need to fill support engineer roles. If anybody interested for positions in the US / Europe please send me an email.

ems...@ho...


Thanks a lot,
Eduardo Serrat


________________________________
From: David Miller <da...@da...>
Sent: Sunday, April 21, 2019 6:25 PM
To: cl...@ba... <cl...@ba...>
Cc: co...@lw... <co...@lw...>; lin...@vg... <lin...@vg...>; ne...@vg... <ne...@vg...>; lin...@li... <lin...@li...>; lin...@vg... <lin...@vg...>; tg...@su... <tg...@su...>
Subject: Re: [Linux-decnet-user] [PATCH] Documentation: decnet: remove reference to CONFIG_DECNET_ROUTE_FWMARK

From: Corentin Labbe <cl...@ba...>
Date: Sat, 20 Apr 2019 16:43:01 +0000

> CONFIG_DECNET_ROUTE_FWMARK was removed in commit 47dcf0cb1005 ("[NET]: Rethink mark field in struct flowi")
> Since nothing replace it (and nothindg need to replace it, simply remove
> it from documentation.
>
> Signed-off-by: Corentin Labbe <cl...@ba...>

Applied.


_______________________________________________
Project Home Page: http://linux-decnet.wiki.sourceforge.net/

Linux-decnet-user mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-decnet-user

Re: [Linux-decnet-user] [PATCH] Documentation: decnet: remove reference to CONFIG_DECNET_ROUTE_FWMARK

[David M. <da...@da...>]

From: Corentin Labbe <cl...@ba...>
Date: Sat, 20 Apr 2019 16:43:01 +0000

> CONFIG_DECNET_ROUTE_FWMARK was removed in commit 47dcf0cb1005 ("[NET]: Rethink mark field in struct flowi")
> Since nothing replace it (and nothindg need to replace it, simply remove
> it from documentation.
> 
> Signed-off-by: Corentin Labbe <cl...@ba...>

Applied.

Re: [Linux-decnet-user] [PATCH] decnet: fix DN_IFREQ_SIZE

[David M. <da...@re...>]

From: Johannes Berg <joh...@si...>
Date: Sat, 26 Jan 2019 21:12:19 +0100

> From: Johannes Berg <joh...@in...>
> 
> Digging through the ioctls with Al because of the previous
> patches, we found that on 64-bit decnet's dn_dev_ioctl()
> is wrong, because struct ifreq::ifr_ifru is actually 24
> bytes (not 16 as expected from struct sockaddr) due to the
> ifru_map and ifru_settings members.
> 
> Clearly, decnet expects the ioctl to be called with a struct
> like
>   struct ifreq_dn {
>     char ifr_name[IFNAMSIZ];
>     struct sockaddr_dn ifr_addr;
>   };
> 
> since it does
>   struct ifreq *ifr = ...;
>   struct sockaddr_dn *sdn = (struct sockaddr_dn *)&ifr->ifr_addr;
> 
> This means that DN_IFREQ_SIZE is too big for what it wants on
> 64-bit, as it is
>   sizeof(struct ifreq) - sizeof(struct sockaddr) +
>   sizeof(struct sockaddr_dn)
> 
> This assumes that sizeof(struct sockaddr) is the size of ifr_ifru
> but that isn't true.
> 
> Fix this to use offsetof(struct ifreq, ifr_ifru).
> 
> This indeed doesn't really matter much - the result is that we
> copy in/out 8 bytes more than we should on 64-bit platforms. In
> case the "struct ifreq_dn" lands just on the end of a page though
> it might lead to faults.
> 
> As far as I can tell, it has been like this forever, so it seems
> very likely that nobody cares.
> 
> Signed-off-by: Johannes Berg <joh...@in...>

Applied.

Re: [Linux-decnet-user] [PATCH net-next] net, decnet: use struct_size() in kzalloc()

[David M. <da...@da...>]

From: "Gustavo A. R. Silva" <gu...@em...>
Date: Tue, 15 Jan 2019 13:50:06 -0600

> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
> 
> struct foo {
>     int stuff;
>     struct boo entry[];
> };
> 
> instance = kzalloc(sizeof(struct foo) + count * sizeof(struct boo), GFP_KERNEL);
> 
> Instead of leaving these open-coded and prone to type mistakes, we can now
> use the new struct_size() helper:
> 
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva <gu...@em...>

Applied, thanks.

Re: [Linux-decnet-user] [PATCH] net/decnet: add missing indentation

[David M. <da...@da...>]

From: Colin King <col...@ca...>
Date: Tue, 13 Nov 2018 14:18:17 +0000

> From: Colin Ian King <col...@ca...>
> 
> There is a missing indentation before the declaration of port. Add
> it.
> 
> Signed-off-by: Colin Ian King <col...@ca...>

Applied.

Re: [Linux-decnet-user] [PATCH net-next] decnet: fix using plain integer as NULL warning

[David M. <da...@da...>]

From: YueHaibing <yue...@hu...>
Date: Wed, 8 Aug 2018 19:59:32 +0800

> Fixes the following sparse warning:
> net/decnet/dn_route.c:407:30: warning: Using plain integer as NULL pointer
> net/decnet/dn_route.c:1923:22: warning: Using plain integer as NULL pointer
> 
> Signed-off-by: YueHaibing <yue...@hu...>

Applied.

Re: [Linux-decnet-user] [PATCH PATCH net-next 00/18] net whitespace cleanups

[David M. <da...@da...>]

From: Stephen Hemminger <st...@ne...>
Date: Tue, 24 Jul 2018 12:29:00 -0700

> Ran script that I use to check for trailing whitespace and
> blank lines at end of files across all files in net/ directory.
> These are errors that checkpatch reports and git flags.
> 
> These are the resulting fixes broken up mostly by subsystem.

I skipped 9p, ceph, and sunrpc since those don't go via my tree.

I applied the rest because it's mostly small and won't cause too
many conflicts in the future.

Thanks.

Re: [Linux-decnet-user] [PATCH] net: decnet: dn_nsp_in: mark expected switch fall-through

[David M. <da...@da...>]

From: "Gustavo A. R. Silva" <gu...@em...>
Date: Wed, 4 Jul 2018 17:05:00 -0500

> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva <gu...@em...>

Applied.

Re: [Linux-decnet-user] [PATCH 3/4] net: Use octal not symbolic permissions

[David M. <da...@da...>]

Applied.

[Linux-decnet-user] kernel module

[Erik O. <e.o...@xs...>]

Just a note that here:

http://rullf2.xs4all.nl/decnet/

a few changes may be found to make the kernel module work under recent Linux versions.

Re: [Linux-decnet-user] [PATCH net] dn_getsockoptdecnet: move nf_{get/set}sockopt outside sock lock

[David M. <da...@da...>]

From: Paolo Abeni <pa...@re...>
Date: Thu, 15 Feb 2018 16:59:49 +0100

> After commit 3f34cfae1238 ("netfilter: on sockopt() acquire sock lock
> only in the required scope"), the caller of nf_{get/set}sockopt() must
> not hold any lock, but, in such changeset, I forgot to cope with DECnet.
> 
> This commit addresses the issue moving the nf call outside the lock,
> in the dn_{get,set}sockopt() with the same schema currently used by
> ipv4 and ipv6. Also moves the unhandled sockopts of the end of the main
> switch statements, to improve code readability.
> 
> Reported-by: Petr Vandrovec <pe...@va...>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198791#c2
> Fixes: 3f34cfae1238 ("netfilter: on sockopt() acquire sock lock only in the required scope")
> Signed-off-by: Paolo Abeni <pa...@re...>

Applied, thank you.

Re: [Linux-decnet-user] [PATCH v2] net: make getname() functions return length rather than use int* parameter

[David M. <da...@da...>]

From: Denys Vlasenko <dvl...@re...>
Date: Mon, 12 Feb 2018 20:00:20 +0100

> Changes since v1:
> Added changes in these files:
>     drivers/infiniband/hw/usnic/usnic_transport.c
>     drivers/staging/lustre/lnet/lnet/lib-socket.c
>     drivers/target/iscsi/iscsi_target_login.c
>     drivers/vhost/net.c
>     fs/dlm/lowcomms.c
>     fs/ocfs2/cluster/tcp.c
>     security/tomoyo/network.c
> 
> 
> Before:
> All these functions either return a negative error indicator,
> or store length of sockaddr into "int *socklen" parameter
> and return zero on success.
> 
> "int *socklen" parameter is awkward. For example, if caller does not
> care, it still needs to provide on-stack storage for the value
> it does not need.
> 
> None of the many FOO_getname() functions of various protocols
> ever used old value of *socklen. They always just overwrite it.
> 
> This change drops this parameter, and makes all these functions, on success,
> return length of sockaddr. It's always >= 0 and can be differentiated
> from an error.
> 
> Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.
> 
> rpc_sockname() lost "int buflen" parameter, since its only use was
> to be passed to kernel_getsockname() as &buflen and subsequently
> not used in any way.
> 
> Userspace API is not changed.
> 
>     text    data     bss      dec     hex filename
> 30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
> 30108109 2633612  873672 33615393 200ee21 vmlinux.o
> 
> Signed-off-by: Denys Vlasenko <dvl...@re...>

Applied to net-next, thanks Denys.

Re: [Linux-decnet-user] [PATCH] net: make getname() functions return length rather than use int* parameter

[David M. <da...@da...>]

From: Denys Vlasenko <dvl...@re...>
Date: Mon, 12 Feb 2018 15:15:18 +0100

> Before:
> All these functions either return a negative error indicator,
> or store length of sockaddr into "int *socklen" parameter
> and return zero on success.
> 
> "int *socklen" parameter is awkward. For example, if caller does not
> care, it still needs to provide on-stack storage for the value
> it does not need.
> 
> None of the many FOO_getname() functions of various protocols
> ever used old value of *socklen. They always just overwrite it.
> 
> This change drops this parameter, and makes all these functions, on success,
> return length of sockaddr. It's always >= 0 and can be differentiated
> from an error.
> 
> Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.
> 
> rpc_sockname() lost "int buflen" parameter, since its only use was
> to be passed to kernel_getsockname() as &buflen and subsequently
> not used in any way.
> 
> Userspace API is not changed.
> 
>     text    data     bss      dec     hex filename
> 30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
> 30108109 2633612  873672 33615393 200ee21 vmlinux.o
> 
> Signed-off-by: Denys Vlasenko <dvl...@re...>

Please do an allmodconfig build, there are still some conversions you
missed:

security/tomoyo/network.c: In function ‘tomoyo_socket_listen_permission’:
security/tomoyo/network.c:658:19: warning: passing argument 3 of ‘sock->ops->getname’ makes integer from pointer without a cast [-Wint-conversion]
            &addr, &addr_len, 0);
                   ^
security/tomoyo/network.c:658:19: note: expected ‘int’ but argument is of type ‘int *’
security/tomoyo/network.c:657:21: error: too many arguments to function ‘sock->ops->getname’
   const int error = sock->ops->getname(sock, (struct sockaddr *)
                     ^~~~
fs/dlm/lowcomms.c: In function ‘lowcomms_error_report’:
fs/dlm/lowcomms.c:495:6: error: too many arguments to function ‘kernel_getpeername’
      kernel_getpeername(con->sock, (struct sockaddr *)&saddr, &buflen)) {
      ^~~~~~~~~~~~~~~~~~
fs/dlm/lowcomms.c: In function ‘tcp_accept_from_sock’:
fs/dlm/lowcomms.c:761:7: warning: passing argument 3 of ‘newsock->ops->getname’ makes integer from pointer without a cast [-Wint-conversion]
       &len, 2)) {
       ^
fs/dlm/lowcomms.c:761:7: note: expected ‘int’ but argument is of type ‘int *’
fs/dlm/lowcomms.c:760:6: error: too many arguments to function ‘newsock->ops->getname’
  if (newsock->ops->getname(newsock, (struct sockaddr *)&peeraddr,
      ^~~~~~~

Re: [Linux-decnet-user] [PATCH] net: decnet: dn_table: mark expected switch fall-through

[David M. <da...@da...>]

From: "Gustavo A. R. Silva" <gar...@em...>
Date: Wed, 8 Nov 2017 21:38:28 -0600

> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Addresses-Coverity-ID: 115106
> Signed-off-by: Gustavo A. R. Silva <gar...@em...>

Applied.

Re: [Linux-decnet-user] [PATCH] net: decnet: dn_nsp_out: use swap macro in dn_mk_ack_header

[David M. <da...@da...>]

From: "Gustavo A. R. Silva" <gar...@em...>
Date: Sat, 28 Oct 2017 15:39:48 -0500

> Make use of the swap macro and remove unnecessary variable tmp.
> This makes the code easier to read and maintain.
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva <gar...@em...>

Applied.

Re: [Linux-decnet-user] [PATCH] net: decnet: dn_nsp_in: use swap macro in dn_nsp_rx_packet

[David M. <da...@da...>]

From: "Gustavo A. R. Silva" <gar...@em...>
Date: Sat, 28 Oct 2017 14:38:45 -0500

> Make use of the swap macro and remove unnecessary variable tmp.
> This makes the code easier to read and maintain.
> 
> This code was detected with the help of Coccinelle.
> 
> Signed-off-by: Gustavo A. R. Silva <gar...@em...>

Applied.

Re: [Linux-decnet-user] [PATCH] decnet: af_decnet: mark expected switch fall-throughs

[David M. <da...@da...>]

From: "Gustavo A. R. Silva" <gar...@em...>
Date: Mon, 16 Oct 2017 15:11:22 -0500

> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva <gar...@em...>

Applied.

Re: [Linux-decnet-user] [PATCH 00/36] v2 net subsystem misc refcounter conversions

[David M. <da...@da...>]

From: Elena Reshetova <ele...@in...>
Date: Tue,  4 Jul 2017 15:52:55 +0300

> Changes in v2:
>  * rebase on top of net-next
>  * currently by default refcount_t = atomic_t (*) and uses all 
>    atomic standard operations unless CONFIG_REFCOUNT_FULL is enabled.
>    This is a compromise for the systems that are critical on
>    performance (such as net) and cannot accept even slight delay
>    on the refcounter operations.
> 
> This series, for various misc network components, replaces atomic_t reference
> counters with the new refcount_t type and API (see include/linux/refcount.h).
> By doing this we prevent intentional or accidental
> underflows or overflows that can led to use-after-free vulnerabilities.
> These are the last networking-related conversions with the exception of
> network drivers (to be send separately).
> 
> Please excuse the long patch set, but seems like breaking it up
> won't save that much on CC list and most of the changes are
> trivial.
> 
> The patches are fully independent and can be cherry-picked separately.
> In order to try with refcount functionality enabled in run-time,
> CONFIG_REFCOUNT_FULL must be enabled.
> 
> NOTE: automatic kernel builder for some reason doesn't like all my
> network branches and regularly times out the builds on these branches.
> Suggestion for "waiting a day for a good coverage" doesn't work, as
> we have seen with generic network conversions. So please wait for the
> full report from kernel test rebot before merging further up.
> This has been compile-tested in 116 configs, but 71 timed out (including
> all s390-related configs again). I am trying to see if they can fix
> build coverage for me in meanwhile.
> 
> * The respective change is currently merged into -next as
>   "locking/refcount: Create unchecked atomic_t implementation".

Series applied, that's enough for this cycle, please.

Re: [Linux-decnet-user] [PATCH v2] decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb

[David M. <da...@da...>]

From: Mateusz Jurczyk <mju...@go...>
Date: Wed, 7 Jun 2017 16:41:57 +0200

> On Wed, Jun 7, 2017 at 4:18 PM, Florian Westphal <fw...@st...> wrote:
>> Mateusz Jurczyk <mju...@go...> wrote:
>>> Verify that the length of the socket buffer is sufficient to cover the
>>> nlmsghdr structure before accessing the nlh->nlmsg_len field for further
>>> input sanitization. If the client only supplies 1-3 bytes of data in
>>> sk_buff, then nlh->nlmsg_len remains partially uninitialized and
>>> contains leftover memory from the corresponding kernel allocation.
>>> Operating on such data may result in indeterminate evaluation of the
>>> nlmsg_len < sizeof(*nlh) expression.
>>>
>>> The bug was discovered by a runtime instrumentation designed to detect
>>> use of uninitialized memory in the kernel. The patch prevents this and
>>> other similar tools (e.g. KMSAN) from flagging this behavior in the future.
>>
>> Instead of changing all the internal users wouldn't it be better
>> to add this check once in netlink_unicast_kernel?
>>
> 
> Perhaps. I must admit I'm not very familiar with this code
> area/interface, so I preferred to fix the few specific cases instead
> of submitting a general patch, which might have some unexpected side
> effects, e.g. behavior different from one of the internal clients etc.
> 
> If you think one check in netlink_unicast_kernel is a better way to do
> it, I'm happy to implement it like that.

Until we decide to add the check to netlink_unicast_kernel(), I'm applying
this and queueing it up for -stable.

Thanks.