* Re: [PATCH 00/36] Convert DocBook documents to ReST
From: Jonathan Corbet @ 2017-05-15 17:11 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Andrew Lunn, alsa-devel, Linux Doc Mailing List, Takashi Iwai,
Jan Kiszka, Herton R. Krzesinski, Alexei Starovoitov,
Takashi Iwai, J. Bruce Fields, linux-ide, Eric Dumazet, netdev,
Jeff Layton, Jan Kara, Soheil Hassas Yeganeh, linux-s390,
Florian Fainelli, James E.J. Bottomley, Herbert Xu, linux-scsi,
Ursula Braun, Rafael J. Wysocki, Peter Zijlstra, Julian Anastasov,
Ingo
In-Reply-To: <cover.1494596071.git.mchehab@s-opensource.com>
On Fri, 12 May 2017 10:59:43 -0300
Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
> This patch series convert the following books from
> DocBook to ReST:
>
> - filesystems
> - kernel-hacking
> - kernel-locking
> - kgdb
> - libata
> - networking
> - rapidio
> - s390-drivers
> - scsi
> - w1
> - z8530book
>
> It also adjusts some Sphinx-pedantic errors/warnings on
> some kernel-doc markups.
>
> I also added some patches here to add PDF output for all
> existing ReST books.
So I've been through the series (including digging out the parts that
weren't sent to me).
> I did my best to check if what's there is not too outdated, but
> the best is if the subsystem maintainers could check it.
That has been my real concern with those remaining books; many of them
have not been touched in any significant way in at least ten years. Just
shoveling a bunch of stuff into RST doesn't really solve the problem that
Documentation/ is an unorganized jumble of sometimes highly outdated
documentation.
But, then, I guess there's value in having a disorganized jumble that
depends on only one fragile toolchain rather than two :) So maybe we
should just do this.
I only had one real comment with the series beyond the general stuff
here. I see Markus had a few. When the tweaks are done, can you send me
a series for the stuff I can apply, and I'll do it?
Thanks,
jon
^ permalink raw reply
* Your first payment of $5000 ,
From: Mrs. Linda Jones @ 2017-05-15 17:16 UTC (permalink / raw)
Attn Beneficiary,
We have deposited the check of your fund ($2.5m USD) through western union money transfer
department after our finally meeting today regarding your fund, Now all you
will do is to contact western union director Mis Rose Kelly ,And She will give you
the direction on how you will be receiving your funds daily. Remember to send
her your Full information to avoid wrong transfer such as,
Your Receiver Name--------------
Your Country--------------------
Your City-----------------------
Your Phone No-----------------------
Your Address--------------------
Your Id card or pasport :.......
Therefore you are advised to contact western union accountant Manager
to her bellow information and tell She to give you the Mtcn, sender name
and question/answer to pick the money,
CONTACT Name: Mis Rose Kelly reply to ( wstun.office123@gmail.com )
Phone: +229-99374614
Get back to us once you receive your total fund of $2.5m.
Thanks and God bless you.
Best Regards
WESTERN UNION AGENT
^ permalink raw reply
* Re: [PATCH] mdio: mux: fix device_node_continue.cocci warnings
From: Jon Mason @ 2017-05-15 17:37 UTC (permalink / raw)
To: Florian Fainelli
Cc: David Miller, Julia Lawall, Network Development, Andrew Lunn,
kbuild-all, open list
In-Reply-To: <872f3980-9faa-718f-3260-9e4b22946140@gmail.com>
On Fri, May 12, 2017 at 6:52 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 05/12/2017 09:22 AM, David Miller wrote:
>> From: Julia Lawall <julia.lawall@lip6.fr>
>> Date: Fri, 12 May 2017 22:54:23 +0800 (SGT)
>>
>>> Device node iterators put the previous value of the index variable, so an
>>> explicit put causes a double put.
>> ...
>>> @@ -169,7 +169,6 @@ int mdio_mux_init(struct device *dev,
>>> if (r) {
>>> mdiobus_free(cb->mii_bus);
>>> devm_kfree(dev, cb);
>>> - of_node_put(child_bus_node);
>>> } else {
>>
>> I think we're instead simply missing a break; statement here.
>
> It's kind of questionable, if we have an error initializing one of our
> child MDIO bus controller (child from the perspective of the MDIO mux,
> boy this is getting complicated...), should we keep on going, or should
> we abort entirely and rollback what we have successfully registered?
>
> I don't think Julia's patch makes thing worse, in that if we had to
> rollback, we would not be doing this correctly now anyway.
>
> Jon, what do you think?
If every other case is fatal, then it is odd that this one is
permissive. I think we should go 100% one way or the other. So, the
options here are to:
1. Encounter an error, unroll any mallocs, etc created by this entry,
but continue on to the next entry and return success if any are
created
2. Encounter an error, unroll any mallocs, etc created by this entry
and any others that were created, and return an error
3. Encounter an error, unroll any mallocs, etc created by this entry,
exit and return success if any are created
#1 would be the most accepting of any errors encountered
#2 would identify any poorly written DTs by breaking their currently
working functionality (though we should add some error messages to let
them know why)
#3 matches the suggestion by David Miller, and would be a hybrid of #1
and #2 in outcome
I would prefer #1, as I would not want to break something that was
currently working. However, I think we should add much error logging
here to let people know their DT is hosed (instead of silently
working). So, this would mean applying Julia's patch, and I'll do a
follow-on to change the breaks to continues and add the error logging
(assuming others agree with me).
Thanks,
Jon
^ permalink raw reply
* Re: [PATCH 00/36] Convert DocBook documents to ReST
From: Mauro Carvalho Chehab @ 2017-05-15 17:41 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Andrew Lunn, alsa-devel, Linux Doc Mailing List, Takashi Iwai,
Jan Kiszka, Herton R. Krzesinski, Alexei Starovoitov,
Takashi Iwai, J. Bruce Fields, linux-ide, Eric Dumazet, netdev,
Jeff Layton, Jan Kara, Soheil Hassas Yeganeh, linux-s390,
Florian Fainelli, James E.J. Bottomley, Herbert Xu, linux-scsi,
Ursula Braun, Rafael J. Wysocki, Peter Zijlstra, Julian Anastasov,
Ingo
In-Reply-To: <20170515111141.0fcd5ee6@lwn.net>
Em Mon, 15 May 2017 11:11:41 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Fri, 12 May 2017 10:59:43 -0300
> Mauro Carvalho Chehab <mchehab@s-opensource.com> wrote:
>
> > This patch series convert the following books from
> > DocBook to ReST:
> >
> > - filesystems
> > - kernel-hacking
> > - kernel-locking
> > - kgdb
> > - libata
> > - networking
> > - rapidio
> > - s390-drivers
> > - scsi
> > - w1
> > - z8530book
> >
> > It also adjusts some Sphinx-pedantic errors/warnings on
> > some kernel-doc markups.
> >
> > I also added some patches here to add PDF output for all
> > existing ReST books.
>
> So I've been through the series (including digging out the parts that
> weren't sent to me).
>
> > I did my best to check if what's there is not too outdated, but
> > the best is if the subsystem maintainers could check it.
>
> That has been my real concern with those remaining books; many of them
> have not been touched in any significant way in at least ten years. Just
> shoveling a bunch of stuff into RST doesn't really solve the problem that
> Documentation/ is an unorganized jumble of sometimes highly outdated
> documentation.
True. Yet, on the checks I did, on the books that have API descriptions,
the C domain references still exist. On the books that just have
kernel-doc tags, I wouldn't expect any changes there, as the API
changes should be, instead, at the C code.
So, I guess that it is not that bad, and, by having them in ReST will
make them easier to be updated, as ReST is basically ascii with benefits.
> But, then, I guess there's value in having a disorganized jumble that
> depends on only one fragile toolchain rather than two :) So maybe we
> should just do this.
>
> I only had one real comment with the series beyond the general stuff
> here. I see Markus had a few. When the tweaks are done, can you send me
> a series for the stuff I can apply, and I'll do it?
Sure, I'm addressing the comments and will send you a new series.
Thanks,
Mauro
^ permalink raw reply
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
From: Kees Cook @ 2017-05-15 17:44 UTC (permalink / raw)
To: Shubham Bansal
Cc: David Miller, Mircea Gherzan, Network Development,
kernel-hardening@lists.openwall.com,
linux-arm-kernel@lists.infradead.org, ast, Daniel Borkmann
In-Reply-To: <CAHgaXdL7GcVzs+ANPke_NywhcgHbe_fzi1sTDEy+Ni1-o82GYQ@mail.gmail.com>
On Sat, May 13, 2017 at 2:38 PM, Shubham Bansal
<illusionist.neo@gmail.com> wrote:
> Finally finished testing.
>
> "test_bpf: Summary: 314 PASSED, 0 FAILED, [274/306 JIT'ed]"
Nice work! Glad you've been chipping away at this. Thanks!
-Kees
>
> Will send the patch after code refactoring. Thanks for all the help
> you guys. I really really appreciate it.
>
> Special thanks to Kees and Daniel. :)
>
> Best,
> Shubham Bansal
>
>
> On Thu, May 11, 2017 at 9:00 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Thu, May 11, 2017 at 2:32 AM, Shubham Bansal
>> <illusionist.neo@gmail.com> wrote:
>>> What do you guys suggest i should implement it? I am almost done with
>>> my current implementation but if you think I should change it to the
>>> way David suggested, its better to suggest now before I send the
>>> patch.
>>
>> I'd say send what you have right now, as it's a good starting point
>> for future work. I'll be curious to see the benchmarks, etc. It can be
>> a base for further optimization.
>>
>> Thanks for chipping away at this!
>>
>> -Kees
>>
>> --
>> Kees Cook
>> Pixel Security
--
Kees Cook
Pixel Security
^ permalink raw reply
* [PATCH net-next 0/2] ldmvsw: port removal stability
From: Shannon Nelson @ 2017-05-15 17:51 UTC (permalink / raw)
To: davem, netdev; +Cc: sparclinux, Shannon Nelson
Under heavy reboot stress testing we found a couple of timing issues
when removing the device that could cause the kernel great heartburn,
addressed by these two patches.
Shannon Nelson (1):
ldmvsw: stop the clean timer at beginning of remove
Thomas Tai (1):
ldmvsw: unregistering netdev before disable hardware
drivers/net/ethernet/sun/ldmvsw.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH net-next 1/2] ldmvsw: unregistering netdev before disable hardware
From: Shannon Nelson @ 2017-05-15 17:51 UTC (permalink / raw)
To: davem, netdev; +Cc: sparclinux, Thomas Tai, Shannon Nelson
In-Reply-To: <1494870668-65047-1-git-send-email-shannon.nelson@oracle.com>
From: Thomas Tai <thomas.tai@oracle.com>
When running LDom binding/unbinding test, kernel may panic
in ldmvsw_open(). It is more likely that because we're removing
the ldc connection before unregistering the netdev in vsw_port_remove(),
we set up a window of time where one process could be removing the
device while another trying to UP the device. This also sometimes causes
vio handshake error due to opening a device without closing it completely.
We should unregister the netdev before we disable the "hardware".
Orabug: 25980913, 25925306
Signed-off-by: Thomas Tai <thomas.tai@oracle.com>
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
drivers/net/ethernet/sun/ldmvsw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/sun/ldmvsw.c b/drivers/net/ethernet/sun/ldmvsw.c
index 5a90fed..309747c 100644
--- a/drivers/net/ethernet/sun/ldmvsw.c
+++ b/drivers/net/ethernet/sun/ldmvsw.c
@@ -413,6 +413,7 @@ static int vsw_port_remove(struct vio_dev *vdev)
del_timer_sync(&port->vio.timer);
napi_disable(&port->napi);
+ unregister_netdev(port->dev);
list_del_rcu(&port->list);
@@ -427,7 +428,6 @@ static int vsw_port_remove(struct vio_dev *vdev)
dev_set_drvdata(&vdev->dev, NULL);
- unregister_netdev(port->dev);
free_netdev(port->dev);
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/2] ldmvsw: stop the clean timer at beginning of remove
From: Shannon Nelson @ 2017-05-15 17:51 UTC (permalink / raw)
To: davem, netdev; +Cc: sparclinux, Shannon Nelson
In-Reply-To: <1494870668-65047-1-git-send-email-shannon.nelson@oracle.com>
Stop the clean timer earlier to be sure there's no asynchronous
interference while stopping the port.
Orabug: 25748241
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
---
drivers/net/ethernet/sun/ldmvsw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/sun/ldmvsw.c b/drivers/net/ethernet/sun/ldmvsw.c
index 309747c..5b56c24 100644
--- a/drivers/net/ethernet/sun/ldmvsw.c
+++ b/drivers/net/ethernet/sun/ldmvsw.c
@@ -411,6 +411,7 @@ static int vsw_port_remove(struct vio_dev *vdev)
if (port) {
del_timer_sync(&port->vio.timer);
+ del_timer_sync(&port->clean_timer);
napi_disable(&port->napi);
unregister_netdev(port->dev);
@@ -418,7 +419,6 @@ static int vsw_port_remove(struct vio_dev *vdev)
list_del_rcu(&port->list);
synchronize_rcu();
- del_timer_sync(&port->clean_timer);
spin_lock_irqsave(&port->vp->lock, flags);
sunvnet_port_rm_txq_common(port);
spin_unlock_irqrestore(&port->vp->lock, flags);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next] geneve: add rtnl changelink support
From: Girish Moodalbail @ 2017-05-15 17:47 UTC (permalink / raw)
To: netdev; +Cc: davem, pshelar, joe, jbenc
This patch adds changelink rtnl operation support for geneve devices.
Code changes involve:
- refactor geneve_newlink into geneve_nl2info to be used by both
geneve_newlink and geneve_changelink
- geneve_nl2info takes a changelink boolean argument to isolate
changelink checks and updates.
- Allow changing only a few attributes:
- return -EOPNOTSUPP for attributes that cannot be changed for
now. Incremental patches can make the non-supported one
available in the future if needed.
Signed-off-by: Girish Moodalbail <girish.moodalbail@oracle.com>
---
drivers/net/geneve.c | 149 ++++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 117 insertions(+), 32 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index dec5d56..6528910 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -1112,6 +1112,18 @@ static bool is_tnl_info_zero(const struct ip_tunnel_info *info)
return true;
}
+static inline bool geneve_dst_addr_equal(struct ip_tunnel_info *a,
+ struct ip_tunnel_info *b)
+{
+ if (ip_tunnel_info_af(a) != ip_tunnel_info_af(b))
+ return false;
+
+ if (ip_tunnel_info_af(a) == AF_INET)
+ return a->key.u.ipv4.dst == b->key.u.ipv4.dst;
+ else
+ return ipv6_addr_equal(&a->key.u.ipv6.dst, &b->key.u.ipv6.dst);
+}
+
static int geneve_configure(struct net *net, struct net_device *dev,
const struct ip_tunnel_info *info,
bool metadata, bool ipv6_rx_csum)
@@ -1169,45 +1181,58 @@ static void init_tnl_info(struct ip_tunnel_info *info, __u16 dst_port)
info->key.tp_dst = htons(dst_port);
}
-static int geneve_newlink(struct net *net, struct net_device *dev,
- struct nlattr *tb[], struct nlattr *data[])
+static int geneve_nl2info(struct net_device *dev, struct nlattr *tb[],
+ struct nlattr *data[], struct ip_tunnel_info *info,
+ bool *metadata, bool *use_udp6_rx_checksums,
+ bool changelink)
{
- bool use_udp6_rx_checksums = false;
- struct ip_tunnel_info info;
- bool metadata = false;
+ struct geneve_dev *geneve = netdev_priv(dev);
- init_tnl_info(&info, GENEVE_UDP_PORT);
+ if (changelink) {
+ /* if changelink operation, start with old existing info */
+ memcpy(info, &geneve->info, sizeof(*info));
+ *metadata = geneve->collect_md;
+ *use_udp6_rx_checksums = geneve->use_udp6_rx_checksums;
+ } else {
+ init_tnl_info(info, GENEVE_UDP_PORT);
+ }
if (data[IFLA_GENEVE_REMOTE] && data[IFLA_GENEVE_REMOTE6])
return -EINVAL;
if (data[IFLA_GENEVE_REMOTE]) {
- info.key.u.ipv4.dst =
+ info->key.u.ipv4.dst =
nla_get_in_addr(data[IFLA_GENEVE_REMOTE]);
- if (IN_MULTICAST(ntohl(info.key.u.ipv4.dst))) {
+ if (IN_MULTICAST(ntohl(info->key.u.ipv4.dst))) {
netdev_dbg(dev, "multicast remote is unsupported\n");
return -EINVAL;
}
+ if (changelink &&
+ ip_tunnel_info_af(&geneve->info) == AF_INET6) {
+ info->mode &= ~IP_TUNNEL_INFO_IPV6;
+ info->key.tun_flags &= ~TUNNEL_CSUM;
+ *use_udp6_rx_checksums = false;
+ }
}
if (data[IFLA_GENEVE_REMOTE6]) {
#if IS_ENABLED(CONFIG_IPV6)
- info.mode = IP_TUNNEL_INFO_IPV6;
- info.key.u.ipv6.dst =
+ info->mode = IP_TUNNEL_INFO_IPV6;
+ info->key.u.ipv6.dst =
nla_get_in6_addr(data[IFLA_GENEVE_REMOTE6]);
- if (ipv6_addr_type(&info.key.u.ipv6.dst) &
+ if (ipv6_addr_type(&info->key.u.ipv6.dst) &
IPV6_ADDR_LINKLOCAL) {
netdev_dbg(dev, "link-local remote is unsupported\n");
return -EINVAL;
}
- if (ipv6_addr_is_multicast(&info.key.u.ipv6.dst)) {
+ if (ipv6_addr_is_multicast(&info->key.u.ipv6.dst)) {
netdev_dbg(dev, "multicast remote is unsupported\n");
return -EINVAL;
}
- info.key.tun_flags |= TUNNEL_CSUM;
- use_udp6_rx_checksums = true;
+ info->key.tun_flags |= TUNNEL_CSUM;
+ *use_udp6_rx_checksums = true;
#else
return -EPFNOSUPPORT;
#endif
@@ -1216,48 +1241,107 @@ static int geneve_newlink(struct net *net, struct net_device *dev,
if (data[IFLA_GENEVE_ID]) {
__u32 vni;
__u8 tvni[3];
+ __be64 tunid;
vni = nla_get_u32(data[IFLA_GENEVE_ID]);
tvni[0] = (vni & 0x00ff0000) >> 16;
tvni[1] = (vni & 0x0000ff00) >> 8;
tvni[2] = vni & 0x000000ff;
- info.key.tun_id = vni_to_tunnel_id(tvni);
+ tunid = vni_to_tunnel_id(tvni);
+ if (changelink && (tunid != info->key.tun_id))
+ return -EOPNOTSUPP;
+ info->key.tun_id = tunid;
}
+
if (data[IFLA_GENEVE_TTL])
- info.key.ttl = nla_get_u8(data[IFLA_GENEVE_TTL]);
+ info->key.ttl = nla_get_u8(data[IFLA_GENEVE_TTL]);
if (data[IFLA_GENEVE_TOS])
- info.key.tos = nla_get_u8(data[IFLA_GENEVE_TOS]);
+ info->key.tos = nla_get_u8(data[IFLA_GENEVE_TOS]);
if (data[IFLA_GENEVE_LABEL]) {
- info.key.label = nla_get_be32(data[IFLA_GENEVE_LABEL]) &
+ info->key.label = nla_get_be32(data[IFLA_GENEVE_LABEL]) &
IPV6_FLOWLABEL_MASK;
- if (info.key.label && (!(info.mode & IP_TUNNEL_INFO_IPV6)))
+ if (info->key.label && (!(info->mode & IP_TUNNEL_INFO_IPV6)))
return -EINVAL;
}
- if (data[IFLA_GENEVE_PORT])
- info.key.tp_dst = nla_get_be16(data[IFLA_GENEVE_PORT]);
+ if (data[IFLA_GENEVE_PORT]) {
+ if (changelink)
+ return -EOPNOTSUPP;
+ info->key.tp_dst = nla_get_be16(data[IFLA_GENEVE_PORT]);
+ }
+
+ if (data[IFLA_GENEVE_COLLECT_METADATA]) {
+ if (changelink)
+ return -EOPNOTSUPP;
+ *metadata = true;
+ }
+
+ if (data[IFLA_GENEVE_UDP_CSUM]) {
+ if (changelink)
+ return -EOPNOTSUPP;
+ if (nla_get_u8(data[IFLA_GENEVE_UDP_CSUM]))
+ info->key.tun_flags |= TUNNEL_CSUM;
+ }
+
+ if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX]) {
+ if (changelink)
+ return -EOPNOTSUPP;
+ if (nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX]))
+ info->key.tun_flags &= ~TUNNEL_CSUM;
+ }
- if (data[IFLA_GENEVE_COLLECT_METADATA])
- metadata = true;
+ if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]) {
+ if (changelink)
+ return -EOPNOTSUPP;
+ if (nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]))
+ *use_udp6_rx_checksums = false;
+ }
- if (data[IFLA_GENEVE_UDP_CSUM] &&
- nla_get_u8(data[IFLA_GENEVE_UDP_CSUM]))
- info.key.tun_flags |= TUNNEL_CSUM;
+ return 0;
+}
- if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX] &&
- nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_TX]))
- info.key.tun_flags &= ~TUNNEL_CSUM;
+static int geneve_newlink(struct net *net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ bool use_udp6_rx_checksums = false;
+ struct ip_tunnel_info info;
+ bool metadata = false;
+ int err;
- if (data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX] &&
- nla_get_u8(data[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]))
- use_udp6_rx_checksums = false;
+ err = geneve_nl2info(dev, tb, data, &info, &metadata,
+ &use_udp6_rx_checksums, false);
+ if (err)
+ return err;
return geneve_configure(net, dev, &info, metadata, use_udp6_rx_checksums);
}
+static int geneve_changelink(struct net_device *dev, struct nlattr *tb[],
+ struct nlattr *data[])
+{
+ struct geneve_dev *geneve = netdev_priv(dev);
+ struct ip_tunnel_info info;
+ bool metadata = false;
+ bool use_udp6_rx_checksums = false;
+ int err;
+
+ err = geneve_nl2info(dev, tb, data, &info, &metadata,
+ &use_udp6_rx_checksums, true);
+ if (err)
+ return err;
+
+ if (!geneve_dst_addr_equal(&geneve->info, &info))
+ dst_cache_reset(&info.dst_cache);
+ geneve->info = info;
+ geneve->collect_md = metadata;
+ geneve->use_udp6_rx_checksums = use_udp6_rx_checksums;
+
+ return 0;
+}
+
static void geneve_dellink(struct net_device *dev, struct list_head *head)
{
struct geneve_dev *geneve = netdev_priv(dev);
@@ -1344,6 +1428,7 @@ static int geneve_fill_info(struct sk_buff *skb, const struct net_device *dev)
.setup = geneve_setup,
.validate = geneve_validate,
.newlink = geneve_newlink,
+ .changelink = geneve_changelink,
.dellink = geneve_dellink,
.get_size = geneve_get_size,
.fill_info = geneve_fill_info,
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE
From: Mahesh Bandewar (महेश बंडेवार) @ 2017-05-15 17:59 UTC (permalink / raw)
To: David Miller
Cc: gregkh, ebiederm, mahesh, mingo, linux-kernel, linux-netdev,
keescook, Eric Dumazet
In-Reply-To: <20170515.095228.1483686375235860235.davem@davemloft.net>
On Mon, May 15, 2017 at 6:52 AM, David Miller <davem@davemloft.net> wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Date: Mon, 15 May 2017 08:10:59 +0200
>
>> On Sun, May 14, 2017 at 08:57:34AM -0500, Eric W. Biederman wrote:
>>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>>>
>>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>>> index bcb0f610ee42..6b72528a4636 100644
>>> --- a/net/core/rtnetlink.c
>>> +++ b/net/core/rtnetlink.c
>>> @@ -2595,7 +2595,7 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh,
>>>
>>> if (!ops) {
>>> #ifdef CONFIG_MODULES
>>> - if (kind[0]) {
>>> + if (kind[0] && capable(CAP_NET_ADMIN)) {
>>> __rtnl_unlock();
>>> request_module("rtnl-link-%s", kind);
>>> rtnl_lock();
>>
>> I don't object to this if the networking developers don't mind the
>> change in functionality. They can handle the fallout :)
>
> As I've said in another email, I am pretty sure this can break things.
The current behavior is already breaking things. e.g. unprivileged
process can be root inside it's own user-ns. This will allow it to
create IPtable rules causing contracking module to be loaded in
default-ns affecting every flow on the server (not just the namespace
that user or an unprivileged process is attached to). Cases that I
mentioned above are just the tip of an iceberg.
In a non-namespace world this wouldn't happen as capability checks are
performed correctly but the moment an unprivileged user can create
it's own user-ns and becomes root inside, it could make use of these
things and perform privileged operations in default-ns. So to protect
"global namespace" from making such things happen, we have to protect
using global capability check.
Alternatively we can preserve the existing behavior by adding this
check for non-default-user-ns only. e.g.
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 6e67315ec368..263f0d175091 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2595,7 +2595,9 @@ static int rtnl_newlink(struct sk_buff *skb,
struct nlmsghdr *nlh,
if (!ops) {
#ifdef CONFIG_MODULES
- if (kind[0]) {
+ if (kind[0] &&
+ ((net->user_ns == &init_user_ns) ||
+ capable(CAP_SYS_MODULE))) {
__rtnl_unlock();
request_module("rtnl-link-%s", kind);
rtnl_lock();
if we have to do this in net-subsystem then it's not just this call
site and there are lot more. But if this is an acceptable alternative,
I can think of better implementation for all those sites.
^ permalink raw reply related
* Re: [PATCH] arp: honour gratuitous ARP _replies_
From: David Miller @ 2017-05-15 18:08 UTC (permalink / raw)
To: ihrachys; +Cc: jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20170510001607.9716-1-ihrachys@redhat.com>
From: Ihar Hrachyshka <ihrachys@redhat.com>
Date: Tue, 9 May 2017 17:16:07 -0700
> @@ -842,8 +844,20 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
> It is possible, that this option should be enabled for some
> devices (strip is candidate)
> */
> - is_garp = arp->ar_op == htons(ARPOP_REQUEST) && tip == sip &&
> - addr_type == RTN_UNICAST;
> + is_garp = tip == sip && addr_type == RTN_UNICAST;
> +
> + /* Unsolicited ARP _replies_ also require target hwaddr to be
> + * the same as source.
> + */
> + if (is_garp && arp->ar_op == htons(ARPOP_REPLY))
> + is_garp =
> +#if IS_ENABLED(CONFIG_FIREWIRE_NET)
> + /* IPv4 over IEEE 1394 doesn't provide target
> + * hardware address field in its ARP payload.
> + */
> + tha &&
> +#endif
> + !memcmp(tha, sha, dev->addr_len);
>
The ifdefs here make the test harder to understand.
I would suggest removing the ifdef and letting the compiler remove the 'tha'
check if it can.
Thank you.
^ permalink raw reply
* Re: [PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE
From: David Miller @ 2017-05-15 18:14 UTC (permalink / raw)
To: maheshb
Cc: gregkh, ebiederm, mahesh, mingo, linux-kernel, netdev, keescook,
edumazet
In-Reply-To: <CAF2d9jjdouSQYVk3kbWyOUEUe5b8S_Q6_Zx2WE_EBZB1cVeEvA@mail.gmail.com>
From: Mahesh Bandewar (महेश बंडेवार) <maheshb@google.com>
Date: Mon, 15 May 2017 10:59:55 -0700
> The current behavior is already breaking things. e.g. unprivileged
> process can be root inside it's own user-ns. This will allow it to
> create IPtable rules causing contracking module to be loaded in
> default-ns affecting every flow on the server (not just the namespace
> that user or an unprivileged process is attached to). Cases that I
> mentioned above are just the tip of an iceberg.
Yes, that is certainly undesirable.
But is it really a module loading problem? Perhaps we need to look
more deeply into how conntract behaves by default wrt. namespaces.
If we've given the user the ability to be root in his or her own
namespace, then we should let them do root stuff in there.
The only problem is when "doing root stuff in there" has an
undesirable impact upon the rest of the system.
And that's needs to be looked into on a facility by facility basis,
rather then just sprinkling "no module loading" test here and there,
or even unconditionally.
^ permalink raw reply
* Re: [PATCH net] macvlan: Fix performance issues with vlan tagged packets
From: David Miller @ 2017-05-15 18:17 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, jasowang, mst, vyasevic
In-Reply-To: <1494515392-30826-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Thu, 11 May 2017 11:09:52 -0400
> Macvlan always turns on offload features that have sofware
> fallback (NETIF_GSO_SOFTWARE). This allows much higher guest-guest
> communications over macvtap.
>
> However, macvtap does not turn on these features for vlan tagged traffic.
> As a result, depending on the HW that mactap is configured on, the
> performance of guest-guest communication over a vlan is very
> inconsistent. If the HW supports TSO/UFO over vlans, then the
> performance will be fine. If not, the the performance will suffer
> greatly since the VM may continue using TSO/UFO, and will force the host
> segment the traffic and possibly overlow the macvtap queue.
>
> This patch adds the always on offloads to vlan_features. This
> makes sure that any vlan tagged traffic between 2 guest will not
> be segmented needlessly.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Indeed, this makes us more consistent with how we handle non-vlan
features in macvtap.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] kmod: don't load module unless req process has CAP_SYS_MODULE
From: Eric W. Biederman @ 2017-05-15 18:20 UTC (permalink / raw)
To: Mahesh Bandewar (महेश बंडेवार)
Cc: David Miller, gregkh, mahesh, mingo, linux-kernel, linux-netdev,
keescook, Eric Dumazet
In-Reply-To: <CAF2d9jjdouSQYVk3kbWyOUEUe5b8S_Q6_Zx2WE_EBZB1cVeEvA@mail.gmail.com>
"Mahesh Bandewar (महेश बंडेवार)" <maheshb@google.com> writes:
> On Mon, May 15, 2017 at 6:52 AM, David Miller <davem@davemloft.net> wrote:
>> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Date: Mon, 15 May 2017 08:10:59 +0200
>>
>>> On Sun, May 14, 2017 at 08:57:34AM -0500, Eric W. Biederman wrote:
>>>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>>>>
>>>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>>>> index bcb0f610ee42..6b72528a4636 100644
>>>> --- a/net/core/rtnetlink.c
>>>> +++ b/net/core/rtnetlink.c
>>>> @@ -2595,7 +2595,7 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh,
>>>>
>>>> if (!ops) {
>>>> #ifdef CONFIG_MODULES
>>>> - if (kind[0]) {
>>>> + if (kind[0] && capable(CAP_NET_ADMIN)) {
>>>> __rtnl_unlock();
>>>> request_module("rtnl-link-%s", kind);
>>>> rtnl_lock();
>>>
>>> I don't object to this if the networking developers don't mind the
>>> change in functionality. They can handle the fallout :)
>>
>> As I've said in another email, I am pretty sure this can break things.
>
> The current behavior is already breaking things. e.g. unprivileged
> process can be root inside it's own user-ns. This will allow it to
> create IPtable rules causing contracking module to be loaded in
> default-ns affecting every flow on the server (not just the namespace
> that user or an unprivileged process is attached to). Cases that I
> mentioned above are just the tip of an iceberg.
If loading the conntrack module changes the semantics of packet
processing when nothing is configured that is a bug in the conntrack
module.
> In a non-namespace world this wouldn't happen as capability checks are
> performed correctly but the moment an unprivileged user can create
> it's own user-ns and becomes root inside, it could make use of these
> things and perform privileged operations in default-ns. So to protect
> "global namespace" from making such things happen, we have to protect
> using global capability check.
>
> Alternatively we can preserve the existing behavior by adding this
> check for non-default-user-ns only. e.g.
I believe last time this was discussed the compromise was that a prefix
would be prepended to request_module calls so that what each call
allows to be loaded would be limited in scope to what is sensible
in that location.
I don't think anyone made any arguments about increasing the
attack surface at that time. So there may be reason to go back
and reexamine the decision on security grounds, but it needs
to be a clearly made argument. Explaining to people the pros and cons
of the reason to perform the work.
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 6e67315ec368..263f0d175091 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2595,7 +2595,9 @@ static int rtnl_newlink(struct sk_buff *skb,
> struct nlmsghdr *nlh,
>
> if (!ops) {
> #ifdef CONFIG_MODULES
> - if (kind[0]) {
> + if (kind[0] &&
> + ((net->user_ns == &init_user_ns) ||
> + capable(CAP_SYS_MODULE))) {
> __rtnl_unlock();
> request_module("rtnl-link-%s", kind);
> rtnl_lock();
This patch is definitely wrong. CAP_NET_ADMIN had always guarded this
request_module call. CAP_SYS_MODULE means you can request any module
you like dropping does not mean you can't request modules.
Adding a capable(CAP_NET_ADMIN) at this call site would be the least
breaking solution available, as it would only break things for callers
in non-initial network namespaces. Your change would definitely things
for ordinary network administration tools with capabilities.
> if we have to do this in net-subsystem then it's not just this call
> site and there are lot more. But if this is an acceptable alternative,
> I can think of better implementation for all those sites.
Eric
^ permalink raw reply
* Re: [PATCH v4] net/mlx4_core: Use min3 to select number of MSI-X vectors
From: David Miller @ 2017-05-15 18:20 UTC (permalink / raw)
To: yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA
Cc: yishaih-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1494569451-2567-1-git-send-email-yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
From: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date: Fri, 12 May 2017 09:10:51 +0300
> Signed-off-by: Yuval Shaia <yuval.shaia-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> ---
> v0 -> v1:
> * s/"min_t("/"min_t(int"
> v1 -> v2:
> * Use min3 instead of min_t twice
> v2 -> v3:
> * Change commit log header message to reflect the changes made in
> v2
> v3 -> v4:
> * Cast return value from num_online_cpus to int to avoid
> compilation errors from "sparse"
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net/packet: fix missing net_device reference release
From: David Miller @ 2017-05-15 18:25 UTC (permalink / raw)
To: douglascs
Cc: netdev, edumazet, daniel, willemb, jarno, andreyknvl, anoob.soman,
sowmini.varadhan, philip.pettersson, rppt
In-Reply-To: <7daebe52-8542-87cb-551a-1a5b4912f140@taghos.com.br>
From: Douglas Caetano dos Santos <douglascs@taghos.com.br>
Date: Fri, 12 May 2017 15:19:15 -0300
> When using a TX ring buffer, if an error occurs processing a control
> message (e.g. invalid message), the net_device reference is not
> released.
>
> Fixes c14ac9451c348 ("sock: enable timestamping using control messages")
> Signed-off-by: Douglas Caetano dos Santos <douglascs@taghos.com.br>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv6: avoid dad-failures for addresses with NODAD
From: David Miller @ 2017-05-15 18:26 UTC (permalink / raw)
To: mahesh; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, edumazet, maheshb
In-Reply-To: <20170513000339.15843-1-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Fri, 12 May 2017 17:03:39 -0700
> From: Mahesh Bandewar <maheshb@google.com>
>
> Every address gets added with TENTATIVE flag even for the addresses with
> IFA_F_NODAD flag and dad-work is scheduled for them. During this DAD process
> we realize it's an address with NODAD and complete the process without
> sending any probe. However the TENTATIVE flags stays on the
> address for sometime enough to cause misinterpretation when we receive a NS.
> While processing NS, if the address has TENTATIVE flag, we mark it DADFAILED
> and endup with an address that was originally configured as NODAD with
> DADFAILED.
>
> We can't avoid scheduling dad_work for addresses with NODAD but we can
> avoid adding TENTATIVE flag to avoid this racy situation.
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
This doesn't apply cleanly to the net tree, please respin.
Thank you.
^ permalink raw reply
* Re: [PATCH] mdio: mux: fix device_node_continue.cocci warnings
From: David Miller @ 2017-05-15 18:29 UTC (permalink / raw)
To: jon.mason
Cc: f.fainelli, julia.lawall, netdev, andrew, kbuild-all,
linux-kernel
In-Reply-To: <CAC3K-4qtjNOfseuENeg2Q7-xKVCK-Ytz2wPQMcX_LiwPLuTAiw@mail.gmail.com>
From: Jon Mason <jon.mason@broadcom.com>
Date: Mon, 15 May 2017 13:37:09 -0400
> I would prefer #1, as I would not want to break something that was
> currently working. However, I think we should add much error logging
> here to let people know their DT is hosed (instead of silently
> working). So, this would mean applying Julia's patch, and I'll do a
> follow-on to change the breaks to continues and add the error logging
> (assuming others agree with me).
Ok, I've applied Julia's patch.
I agree that we shouldn't fail the whole list just because one does.
And yes, we should emit enough diagnostics so that people can figure
out what the problem is.
^ permalink raw reply
* Re: [PATCH net] ipv6: avoid dad-failures for addresses with NODAD
From: David Miller @ 2017-05-15 18:32 UTC (permalink / raw)
To: mahesh; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, edumazet, maheshb
In-Reply-To: <20170515.142655.1279898304018190599.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 15 May 2017 14:26:55 -0400 (EDT)
> From: Mahesh Bandewar <mahesh@bandewar.net>
> Date: Fri, 12 May 2017 17:03:39 -0700
>
>> From: Mahesh Bandewar <maheshb@google.com>
>>
>> Every address gets added with TENTATIVE flag even for the addresses with
>> IFA_F_NODAD flag and dad-work is scheduled for them. During this DAD process
>> we realize it's an address with NODAD and complete the process without
>> sending any probe. However the TENTATIVE flags stays on the
>> address for sometime enough to cause misinterpretation when we receive a NS.
>> While processing NS, if the address has TENTATIVE flag, we mark it DADFAILED
>> and endup with an address that was originally configured as NODAD with
>> DADFAILED.
>>
>> We can't avoid scheduling dad_work for addresses with NODAD but we can
>> avoid adding TENTATIVE flag to avoid this racy situation.
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>
> This doesn't apply cleanly to the net tree, please respin.
Ignore this, I was trying to apply the wrong patch.
Applied, thank you.
^ permalink raw reply
* Re: [Patch net] ipv4: restore rt->fi for reference counting
From: Cong Wang @ 2017-05-15 18:34 UTC (permalink / raw)
To: Julian Anastasov
Cc: Eric Dumazet, David Miller, Linux Kernel Network Developers,
Andrey Konovalov, Eric Dumazet
In-Reply-To: <alpine.LFD.2.20.1705122151001.2835@ja.home.ssi.bg>
On Fri, May 12, 2017 at 2:27 PM, Julian Anastasov <ja@ssi.bg> wrote:
> Now the main question: is FIB_LOOKUP_NOREF used
> everywhere in IPv4? I guess so. If not, it means
> someone can walk its res->fi NHs which is bad. I think,
> this will delay the unregistration for long time and we
> can not solve the problem.
>
> If yes, free_fib_info() should not use call_rcu.
> Instead, fib_release_info() will start RCU callback to
> drop everything via a common function for fib_release_info
> and free_fib_info. As result, the last fib_info_put will
> just need to free fi->fib_metrics and fi.
Yes it is used. But this is a different problem from the
dev refcnt issue, right? I can send a separate patch to
address it.
>> Are you sure we are safe to call dev_put() in fib_release_info()
>> for _all_ paths, especially non-unregister paths? See:
>
> Yep, dev_put is safe there...
>
>> commit e49cc0da7283088c5e03d475ffe2fdcb24a6d5b1
>> Author: Yanmin Zhang <yanmin_zhang@linux.intel.com>
>> Date: Wed May 23 15:39:45 2012 +0000
>>
>> ipv4: fix the rcu race between free_fib_info and ip_route_output_slow
>
> ...as long as we do not set nh_dev to NULL
>
OK, fair enough, then I think the best solution here is to move
the dev_put() from free_fib_info_rcu() to fib_release_info(),
fib_nh is already removed from hash there anyway.
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index da449dd..cb712d1 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -205,8 +205,6 @@ static void free_fib_info_rcu(struct rcu_head *head)
struct fib_info *fi = container_of(head, struct fib_info, rcu);
change_nexthops(fi) {
- if (nexthop_nh->nh_dev)
- dev_put(nexthop_nh->nh_dev);
lwtstate_put(nexthop_nh->nh_lwtstate);
free_nh_exceptions(nexthop_nh);
rt_fibinfo_free_cpus(nexthop_nh->nh_pcpu_rth_output);
@@ -246,6 +244,14 @@ void fib_release_info(struct fib_info *fi)
if (!nexthop_nh->nh_dev)
continue;
hlist_del(&nexthop_nh->nh_hash);
+ /* We have to release these nh_dev here because a dst
+ * could still hold a fib_info via rt->fi, we can't wait
+ * for GC, a socket could hold the dst for a long time.
+ *
+ * This is safe, dev_put() alone does not really free
+ * the netdevice, we just have to put the refcnt back.
+ */
+ dev_put(nexthop_nh->nh_dev);
} endfor_nexthops(fi)
fi->fib_dead = 1;
fib_info_put(fi);
Thanks!
^ permalink raw reply related
* Re: [pull request][net V2 0/5] Mellanox, mlx5 fixes 2017-05-12
From: David Miller @ 2017-05-15 18:38 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20170514104311.2081-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Sun, 14 May 2017 13:43:06 +0300
> This series contains some mlx5 fixes for net.
> Please pull and let me know if there's any problem.
>
> For -stable:
> ("net/mlx5e: Fix ethtool pause support and advertise reporting") kernels >= 4.8
> ("net/mlx5e: Use the correct pause values for ethtool advertising") kernels >= 4.8
>
> v1->v2:
> Dropped statistics spinlock patch, it needs some extra work.
Pulled and the first two patches queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net v2] qed: Fix uninitialized data in aRFS infrastructure
From: David Miller @ 2017-05-15 18:39 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: arnd, netdev
In-Reply-To: <1494753683-3429-1-git-send-email-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Sun, 14 May 2017 12:21:23 +0300
> Current memset is using incorrect type of variable, causing the
> upper-half of the strucutre to be left uninitialized and causing:
>
> ethernet/qlogic/qed/qed_init_fw_funcs.c: In function 'qed_set_rfs_mode_disable':
> ethernet/qlogic/qed/qed_init_fw_funcs.c:993:3: error: '*((void *)&ramline+4)' is used uninitialized in this function [-Werror=uninitialized]
>
> Fixes: d51e4af5c209 ("qed: aRFS infrastructure support")
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Applied, thank you.
^ permalink raw reply
* Re: [net 1/6] net/mlx5e: Use a spinlock to synchronize statistics
From: David Miller @ 2017-05-15 18:39 UTC (permalink / raw)
To: saeedm; +Cc: saeedm, netdev, galp, kernel-team
In-Reply-To: <CALzJLG-CbN5ipg3_CsN9_1RWtY_q_UaQGMu3KwDpgoYk53xkOQ@mail.gmail.com>
From: Saeed Mahameed <saeedm@dev.mellanox.co.il>
Date: Sun, 14 May 2017 11:52:13 +0300
> I agree, it is really ridiculous that we allocate/free a couple of
> buffers on each update_stats operations, regardless of this patch.
> Is it ok if we use a temp buffer under netdev_priv for such usages or
> even use kmemcache ?
If you can safely use a pre-allocated tmp buffer, yes that would be
preferred.
^ permalink raw reply
* Admin
From: administrador @ 2017-05-15 16:26 UTC (permalink / raw)
To: Recipients
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar subuzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono: 0
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es:00916gbd51.17
Correo Soporte Técnico © 2017
¡gracias
Sistemas Administrador
^ permalink raw reply
* Re: [PATCH] net: x25: fix one potential use-after-free issue
From: David Miller @ 2017-05-15 18:47 UTC (permalink / raw)
To: xiaolou4617; +Cc: andrew.hendry, nhorman, linux-x25, netdev, linux-kernel
In-Reply-To: <1494821569-18572-1-git-send-email-xiaolou4617@gmail.com>
From: linzhang <xiaolou4617@gmail.com>
Date: Mon, 15 May 2017 12:12:49 +0800
> The function x25_init is not properly unregister related resources
> on error handler.It is will result in kernel oops if x25_init init
> failed, so add right unregister call on error handler.
>
> Signed-off-by: linzhang <xiaolou4617@gmail.com>
I think we need to go a bit further and make x25_register_sysctl()
properly check for and return failure.
Something like:
diff --git a/include/net/x25.h b/include/net/x25.h
index c383aa4..6d30a01 100644
--- a/include/net/x25.h
+++ b/include/net/x25.h
@@ -298,10 +298,10 @@ void x25_check_rbuf(struct sock *);
/* sysctl_net_x25.c */
#ifdef CONFIG_SYSCTL
-void x25_register_sysctl(void);
+int x25_register_sysctl(void);
void x25_unregister_sysctl(void);
#else
-static inline void x25_register_sysctl(void) {};
+static inline int x25_register_sysctl(void) { return 0; };
static inline void x25_unregister_sysctl(void) {};
#endif /* CONFIG_SYSCTL */
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 8b911c2..b7d6614 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -1808,12 +1808,17 @@ static int __init x25_init(void)
pr_info("Linux Version 0.2\n");
- x25_register_sysctl();
+ rc = x25_register_sysctl();
+ if (rc)
+ goto out_dev;
+
rc = x25_proc_init();
if (rc != 0)
- goto out_dev;
+ goto out_sysctl;
out:
return rc;
+out_sysctl:
+ x25_unregister_sysctl();
out_dev:
unregister_netdevice_notifier(&x25_dev_notifier);
out_sock:
diff --git a/net/x25/sysctl_net_x25.c b/net/x25/sysctl_net_x25.c
index a06dfe1..ba078c8 100644
--- a/net/x25/sysctl_net_x25.c
+++ b/net/x25/sysctl_net_x25.c
@@ -73,9 +73,12 @@ static struct ctl_table x25_table[] = {
{ },
};
-void __init x25_register_sysctl(void)
+int __init x25_register_sysctl(void)
{
x25_table_header = register_net_sysctl(&init_net, "net/x25", x25_table);
+ if (!x25_table_header)
+ return -ENOMEM;
+ return 0;
}
void x25_unregister_sysctl(void)
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox