* [PATCH 1/2 net-next] ibmvnic: Rename IBMVNIC_MAX_TX_QUEUES to IBMVNIC_MAX_QUEUES
From: Thomas Falcon @ 2017-12-18 18:52 UTC (permalink / raw)
To: netdev; +Cc: Thomas Falcon
In-Reply-To: <1513623132-16554-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
This value denotes the maximum number of TX queues but is used
to allocate both RX and TX queues.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
drivers/net/ethernet/ibm/ibmvnic.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 1dc4aef..df6d911 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -4285,7 +4285,7 @@ static int ibmvnic_probe(struct vio_dev *dev, const struct vio_device_id *id)
}
netdev = alloc_etherdev_mq(sizeof(struct ibmvnic_adapter),
- IBMVNIC_MAX_TX_QUEUES);
+ IBMVNIC_MAX_QUEUES);
if (!netdev)
return -ENOMEM;
diff --git a/drivers/net/ethernet/ibm/ibmvnic.h b/drivers/net/ethernet/ibm/ibmvnic.h
index 4487f1e..0f8ef61 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.h
+++ b/drivers/net/ethernet/ibm/ibmvnic.h
@@ -39,7 +39,7 @@
#define IBMVNIC_RX_WEIGHT 16
/* when changing this, update IBMVNIC_IO_ENTITLEMENT_DEFAULT */
#define IBMVNIC_BUFFS_PER_POOL 100
-#define IBMVNIC_MAX_TX_QUEUES 5
+#define IBMVNIC_MAX_QUEUES 5
#define IBMVNIC_TSO_BUF_SZ 65536
#define IBMVNIC_TSO_BUFS 64
--
2.7.5
^ permalink raw reply related
* [PATCH 0/2 net-next] ibmvnic: Fix and increase maximum TX/RX queues
From: Thomas Falcon @ 2017-12-18 18:52 UTC (permalink / raw)
To: netdev; +Cc: Thomas Falcon
This series renames IBMVNIC_MAX_TX_QUEUES to IBMVNIC_MAX_QUEUES since
it is used to allocate both RX and TX queues. The value is also increased
to accommodate newer hardware.
Thomas Falcon (2):
ibmvnic: Rename IBMVNIC_MAX_TX_QUEUES to IBMVNIC_MAX_QUEUES
ibmvnic: Increase maximum number of RX/TX queues
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
drivers/net/ethernet/ibm/ibmvnic.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.7.5
^ permalink raw reply
* Re: [PATCH] ethtool: fix MFLCN register dump for 82599 and newer
From: John W. Linville @ 2017-12-18 18:38 UTC (permalink / raw)
To: Zhang Kang; +Cc: netdev, Gao Wayne, Wei Net
In-Reply-To: <20171215015651.6112-1-tjbroadroad@163.com>
On Fri, Dec 15, 2017 at 09:56:51AM +0800, Zhang Kang wrote:
> Use MFLCN for 82599 and X540 HW instead of FCTRL.
>
> Signed-off-by: Zhang Kang <tjbroadroad@163.com>
> Signed-off-by: Gao Wayne <Wayne.Gao@emc.com>
> Signed-off-by: Wei Net <gw_net@163.com>
Thanks, applied.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
From: Knut Omang @ 2017-12-18 18:39 UTC (permalink / raw)
To: Bart Van Assche, joe@perches.com, jgg@ziepe.ca
Cc: corbet@lwn.net, linux-kernel@vger.kernel.org,
keescook@chromium.org, linux-rdma@vger.kernel.org,
linux-doc@vger.kernel.org, willy@infradead.org,
nicolas.palix@imag.fr, asmund.ostvold@oracle.com,
john.haxby@oracle.com, alexander.levin@verizon.com,
mchehab@kernel.org, haakon.bugge@oracle.com,
michal.lkml@markovi.net, Gilles.Muller@lip6.fr,
yamada.masahiro@socionext.com
In-Reply-To: <1513619815.2798.2.camel@wdc.com>
On Mon, 2017-12-18 at 17:56 +0000, Bart Van Assche wrote:
> On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
> > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
> >
> > > > Today when we run checkers we get so many warnings it is too hard to
> > > > make any sense of it.
> > >
> > > Here is a list of the checkpatch messages for drivers/infiniband
> > > sorted by type.
> > >
> > > Many of these might be corrected by using
> > >
> > > $ ./scripts/checkpatch.pl -f --fix-inplace --types=<TYPE> \
> > > $(git ls-files drivers/infiniband/)
> >
> > How many of these do you think it is worth to fix?
> >
> > We do get a steady trickle of changes in this topic every cycle.
> >
> > Is it better to just do a big number of them all at once? Do you have
> > an idea how disruptive this kind of work is to the whole patch flow
> > eg new patches no longer applying to for-next, backports no longer
> > applying, merge conflicts?
>
> In my opinion patches that only change the coding style and do not change any
> functionality are annoying. Before posting a patch that fixes a bug the change
> history (git log -p) has to be cheched to figure out which patch introduced
> the bug. Patches that only change coding style pollute the change history.
I agree with you - the problem is that style issues should not have existed.
But when they do it becomes a problem to remove them and a problem to
keep them - for instance us who try to be compliant by having style helpers
in our editor, we end up having to manually revert old style mistakes back in
to avoid making unrelated whitespace changes or similar.
I think what we get with this patch set is that there's a way to rein in the
issues and to enable some regression testing without enforcing a lot of work
or annoying history issues *right away*. That way this problem can be tackled when
appropriate for the subsystem in question, and the reason for holding back on
some changes can be documented in the local runchecks.cfg file, focusing
willing helping hands on the issues considered most important for that
subsystem.
Thanks,
Knut
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: arm64: fix uninitialized variable
From: Alexei Starovoitov @ 2017-12-18 18:36 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, David S . Miller
Cc: Arnd Bergmann, netdev, kernel-team
In-Reply-To: <801f283e-293b-251d-1e81-3c08094e1d94@iogearbox.net>
On 12/18/17 10:19 AM, Daniel Borkmann wrote:
> On 12/18/2017 07:09 PM, Alexei Starovoitov wrote:
>> From: Alexei Starovoitov <ast@fb.com>
>>
>> fix the following issue:
>> arch/arm64/net/bpf_jit_comp.c: In function 'bpf_int_jit_compile':
>> arch/arm64/net/bpf_jit_comp.c:982:18: error: 'image_size' may be used
>> uninitialized in this function [-Werror=maybe-uninitialized]
>>
>> Fixes: db496944fdaa ("bpf: arm64: add JIT support for multi-function programs")
>> Reported-by: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>> ---
>> arch/arm64/net/bpf_jit_comp.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
>> index 396490cf7316..acaa935ed977 100644
>> --- a/arch/arm64/net/bpf_jit_comp.c
>> +++ b/arch/arm64/net/bpf_jit_comp.c
>> @@ -897,6 +897,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
>> image_ptr = jit_data->image;
>> header = jit_data->header;
>> extra_pass = true;
>> + image_size = sizeof(u32) * ctx.idx;
>> goto skip_init_ctx;
>> }
>> memset(&ctx, 0, sizeof(ctx));
>>
>
> I don't really mind, but it feels more complex than it needs to be
> imho, since in the initial pass you fetch 'image_size' in fake pass
> from ctx.idx, then we set ctx.idx to 0 again, do another pass and
> use the cached ctx.idx from that second pass instead of the first
> one where we set 'image_size' originally, so we definitely need to
> take that into consideration in future reviews at least.
not sure what you mean.
This check: ctx.idx != jit_data->ctx.idx matters the most.
After first alloc the 'image_size' variable used for dumping only.
That's why the JITing itself worked fine. We could have removed it
since it's computable from idx, but imo it's fine this way.
^ permalink raw reply
* Re: [PATCH net v2] net: bridge: fix early call to br_stp_change_bridge_id and plug newlink leaks
From: David Miller @ 2017-12-18 18:31 UTC (permalink / raw)
To: nikolay; +Cc: netdev, makita.toshiaki, roopa, stephen, avagin, bridge, idosch
In-Reply-To: <20171218153509.7822-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Mon, 18 Dec 2017 17:35:09 +0200
> The early call to br_stp_change_bridge_id in bridge's newlink can cause
> a memory leak if an error occurs during the newlink because the fdb
> entries are not cleaned up if a different lladdr was specified, also
> another minor issue is that it generates fdb notifications with
> ifindex = 0. Another unrelated memory leak is the bridge sysfs entries
> which get added on NETDEV_REGISTER event, but are not cleaned up in the
> newlink error path. To remove this special case the call to
> br_stp_change_bridge_id is done after netdev register and we cleanup the
> bridge on changelink error via br_dev_delete to plug all leaks.
>
> This patch makes netlink bridge destruction on newlink error the same as
> dellink and ioctl del which is necessary since at that point we have a
> fully initialized bridge device.
>
> To reproduce the issue:
> $ ip l add br0 address 00:11:22:33:44:55 type bridge group_fwd_mask 1
> RTNETLINK answers: Invalid argument
>
> $ rmmod bridge
> [ 1822.142525] =============================================================================
> [ 1822.143640] BUG bridge_fdb_cache (Tainted: G O ): Objects remaining in bridge_fdb_cache on __kmem_cache_shutdown()
> [ 1822.144821] -----------------------------------------------------------------------------
...
> Fixes: 30313a3d5794 ("bridge: Handle IFLA_ADDRESS correctly when creating bridge device")
> Fixes: 5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> v2: it's better to use br_dev_delete to clean up because the sysfs entries
> were leaked as well, basically we use it for the bridge fdb flush and sysfs
> entries delete
>
> Consequently this also would fix the null ptr deref due to the rhashtable
> not being initialized in net-next when br_stp_change_bridge_id is called.
Applied, but doing state changes after register_netdev() is always dicey.
I hope things go well if the device is brought up immediately during
that register_netdev() call and before the stp bridge ID setting is
done.
^ permalink raw reply
* Re: [PATCH net-next v3 0/7] net: phy: meson-gxl: clean-up and improvements
From: David Miller @ 2017-12-18 18:25 UTC (permalink / raw)
To: jbrunet
Cc: andrew, f.fainelli, khilman, netdev, linux-arm-kernel,
linux-amlogic, linux-kernel
In-Reply-To: <20171218094446.31912-1-jbrunet@baylibre.com>
From: Jerome Brunet <jbrunet@baylibre.com>
Date: Mon, 18 Dec 2017 10:44:39 +0100
> This patchset adds defines for the control registers and helpers to access
> the banked registers. The goal being to make it easier to understand what
> the driver actually does.
> Then CONFIG_A6 settings is removed since this statement was without effect
> Finally interrupt support is added, speeding things up a little
>
> This series has been tested on the libretech-cc and khadas VIM
>
> Changes since v2 [0]:
> Drop LPA corruption fix which has been merged through net. Apart from this,
> series remains the same.
>
> [0]: https://lkml.kernel.org/r/20171207142715.32578-1-jbrunet@baylibre.com
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: add SCTP_CID_RECONF conversion in sctp_cname
From: David Miller @ 2017-12-18 18:22 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <ae9172b7dc432d6092ab2bc061a0cf322a3939b5.1513577597.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 18 Dec 2017 14:13:17 +0800
> Whenever a new type of chunk is added, the corresp conversion in
> sctp_cname should be added. Otherwise, in some places, pr_debug
> will print it as "unknown chunk".
>
> Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] sctp: fix the issue that a __u16 variable may overflow in sctp_ulpq_renege
From: David Miller @ 2017-12-18 18:22 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <047a7d68a197ff748b48eb8cda4b08fd5b9623fe.1513577245.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 18 Dec 2017 14:07:25 +0800
> Now when reneging events in sctp_ulpq_renege(), the variable freed
> could be increased by a __u16 value twice while freed is of __u16
> type. It means freed may overflow at the second addition.
>
> This patch is to fix it by using __u32 type for 'freed', while at
> it, also to remove 'if (chunk)' check, as all renege commands are
> generated in sctp_eat_data and it can't be NULL.
>
> Reported-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: Change the order of mac up and sgmii open
From: David Miller @ 2017-12-18 18:22 UTC (permalink / raw)
To: hpuranik; +Cc: netdev, linux-kernel, timur
In-Reply-To: <1513576667-2967-1-git-send-email-hpuranik@codeaurora.org>
From: Hemanth Puranik <hpuranik@codeaurora.org>
Date: Mon, 18 Dec 2017 11:27:47 +0530
> This patch fixes the order of mac_up and sgmii_open for the
> reasons noted below:
>
> - If open takes more time(if the SGMII block is not responding or
> if we want to do some delay based task) in this situation we
> will hit NETDEV watchdog
> - The main reason : We should signal to upper layers that we are
> ready to receive packets "only" when the entire path is initialized
> not the other way around, this is followed in the reset path where
> we do mac_down, sgmii_reset and mac_up. This also makes the driver
> uniform across the reset and open paths.
> - In the future there may be need for delay based tasks to be done in
> sgmii open which will result in NETDEV watchdog
> - As per the documentation the order of init should be sgmii, mac, rings
> and DMA
>
> Signed-off-by: Hemanth Puranik <hpuranik@codeaurora.org>
Applied.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: arm64: fix uninitialized variable
From: Daniel Borkmann @ 2017-12-18 18:19 UTC (permalink / raw)
To: Alexei Starovoitov, David S . Miller; +Cc: Arnd Bergmann, netdev, kernel-team
In-Reply-To: <20171218180944.3145591-1-ast@kernel.org>
On 12/18/2017 07:09 PM, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@fb.com>
>
> fix the following issue:
> arch/arm64/net/bpf_jit_comp.c: In function 'bpf_int_jit_compile':
> arch/arm64/net/bpf_jit_comp.c:982:18: error: 'image_size' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>
> Fixes: db496944fdaa ("bpf: arm64: add JIT support for multi-function programs")
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> arch/arm64/net/bpf_jit_comp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
> index 396490cf7316..acaa935ed977 100644
> --- a/arch/arm64/net/bpf_jit_comp.c
> +++ b/arch/arm64/net/bpf_jit_comp.c
> @@ -897,6 +897,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> image_ptr = jit_data->image;
> header = jit_data->header;
> extra_pass = true;
> + image_size = sizeof(u32) * ctx.idx;
> goto skip_init_ctx;
> }
> memset(&ctx, 0, sizeof(ctx));
>
I don't really mind, but it feels more complex than it needs to be
imho, since in the initial pass you fetch 'image_size' in fake pass
from ctx.idx, then we set ctx.idx to 0 again, do another pass and
use the cached ctx.idx from that second pass instead of the first
one where we set 'image_size' originally, so we definitely need to
take that into consideration in future reviews at least.
Thanks,
Daniel
^ permalink raw reply
* Re: [Patch v2] net: phy: marvell: Limit 88m1101 autoneg errata to 88E1145 as well.
From: David Miller @ 2017-12-18 18:19 UTC (permalink / raw)
To: qiang.zhao; +Cc: netdev
In-Reply-To: <20171218022643.47454-1-qiang.zhao@nxp.com>
From: Zhao Qiang <qiang.zhao@nxp.com>
Date: Mon, 18 Dec 2017 10:26:43 +0800
> 88E1145 also need this autoneg errata.
>
> Fixes: f2899788353c ("net: phy: marvell: Limit errata to 88m1101")
> Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
> ---
> Changes for v2
> - modify the commit msg in a proper way.
Applied and queued up for -stable.
^ permalink raw reply
* Re: [trivial PATCH] treewide: Align function definition open/close braces
From: Rafael J. Wysocki @ 2017-12-18 18:19 UTC (permalink / raw)
To: Joe Perches
Cc: linux-rtc, alsa-devel, linuxppc-dev, Jiri Kosina, linux-scsi,
MPT-FusionLinux.pdl, acpi4asus-user, linux-wireless, linux-kernel,
dri-devel, platform-driver-x86, linux-xfs, linux-acpi,
linux-audit, amd-gfx, netdev, linux-fsdevel, Linus Torvalds,
ocfs2-devel, linux-media
In-Reply-To: <1513556924.31581.51.camel@perches.com>
On Monday, December 18, 2017 1:28:44 AM CET Joe Perches wrote:
> Some functions definitions have either the initial open brace and/or
> the closing brace outside of column 1.
>
> Move those braces to column 1.
>
> This allows various function analyzers like gnu complexity to work
> properly for these modified functions.
>
> Miscellanea:
>
> o Remove extra trailing ; and blank line from xfs_agf_verify
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> git diff -w shows no difference other than the above 'Miscellanea'
>
> (this is against -next, but it applies against Linus' tree
> with a couple offsets)
>
> arch/x86/include/asm/atomic64_32.h | 2 +-
> drivers/acpi/custom_method.c | 2 +-
> drivers/acpi/fan.c | 2 +-
> drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
> drivers/media/i2c/msp3400-kthreads.c | 2 +-
> drivers/message/fusion/mptsas.c | 2 +-
> drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 2 +-
> drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
> drivers/platform/x86/eeepc-laptop.c | 2 +-
> drivers/rtc/rtc-ab-b5ze-s3.c | 2 +-
> drivers/scsi/dpt_i2o.c | 2 +-
> drivers/scsi/sym53c8xx_2/sym_glue.c | 2 +-
> fs/locks.c | 2 +-
> fs/ocfs2/stack_user.c | 2 +-
> fs/xfs/libxfs/xfs_alloc.c | 5 ++---
> fs/xfs/xfs_export.c | 2 +-
> kernel/audit.c | 6 +++---
> kernel/trace/trace_printk.c | 4 ++--
> lib/raid6/sse2.c | 14 +++++++-------
> sound/soc/fsl/fsl_dma.c | 2 +-
> 20 files changed, 30 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/include/asm/atomic64_32.h b/arch/x86/include/asm/atomic64_32.h
> index 97c46b8169b7..d4d4883080fa 100644
> --- a/arch/x86/include/asm/atomic64_32.h
> +++ b/arch/x86/include/asm/atomic64_32.h
> @@ -122,7 +122,7 @@ static inline long long atomic64_read(const atomic64_t *v)
> long long r;
> alternative_atomic64(read, "=&A" (r), "c" (v) : "memory");
> return r;
> - }
> +}
>
> /**
> * atomic64_add_return - add and return
> diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
> index c68e72414a67..e967c1173ba3 100644
> --- a/drivers/acpi/custom_method.c
> +++ b/drivers/acpi/custom_method.c
> @@ -94,7 +94,7 @@ static void __exit acpi_custom_method_exit(void)
> {
> if (cm_dentry)
> debugfs_remove(cm_dentry);
> - }
> +}
>
> module_init(acpi_custom_method_init);
> module_exit(acpi_custom_method_exit);
> diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
> index 6cf4988206f2..3563103590c6 100644
> --- a/drivers/acpi/fan.c
> +++ b/drivers/acpi/fan.c
> @@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
> return fan_set_state_acpi4(device, state);
> else
> return fan_set_state(device, state);
> - }
> +}
>
> static const struct thermal_cooling_device_ops fan_cooling_ops = {
> .get_max_state = fan_get_max_state,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index d1488d5ee028..1e0d1e7c5324 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -461,7 +461,7 @@ static void disable_dangling_plane(struct dc *dc, struct dc_state *context)
> ******************************************************************************/
>
> struct dc *dc_create(const struct dc_init_data *init_params)
> - {
> +{
> struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
> unsigned int full_pipe_count;
>
> diff --git a/drivers/media/i2c/msp3400-kthreads.c b/drivers/media/i2c/msp3400-kthreads.c
> index 4dd01e9f553b..dc6cb8d475b3 100644
> --- a/drivers/media/i2c/msp3400-kthreads.c
> +++ b/drivers/media/i2c/msp3400-kthreads.c
> @@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
> }
>
> static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
> - {
> +{
> struct msp_state *state = to_state(i2c_get_clientdata(client));
> int source, matrix;
>
> diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
> index 345f6035599e..69a62d23514b 100644
> --- a/drivers/message/fusion/mptsas.c
> +++ b/drivers/message/fusion/mptsas.c
> @@ -2968,7 +2968,7 @@ mptsas_exp_repmanufacture_info(MPT_ADAPTER *ioc,
> mutex_unlock(&ioc->sas_mgmt.mutex);
> out:
> return ret;
> - }
> +}
>
> static void
> mptsas_parse_device_info(struct sas_identify *identify,
> diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
> index 3dd973475125..0ea141ece19e 100644
> --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
> +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
> @@ -603,7 +603,7 @@ static struct uni_table_desc *nx_get_table_desc(const u8 *unirom, int section)
>
> static int
> netxen_nic_validate_header(struct netxen_adapter *adapter)
> - {
> +{
> const u8 *unirom = adapter->fw->data;
> struct uni_table_desc *directory = (struct uni_table_desc *) &unirom[0];
> u32 fw_file_size = adapter->fw->size;
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index bd438062a6db..baedc7186b10 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -196,7 +196,7 @@ ath_tid_pull(struct ath_atx_tid *tid)
> }
>
> return skb;
> - }
> +}
>
> static struct sk_buff *ath_tid_dequeue(struct ath_atx_tid *tid)
> {
> diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eeepc-laptop.c
> index 5a681962899c..4c38904a8a32 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -492,7 +492,7 @@ static void eeepc_platform_exit(struct eeepc_laptop *eeepc)
> * potentially bad time, such as a timer interrupt.
> */
> static void tpd_led_update(struct work_struct *work)
> - {
> +{
> struct eeepc_laptop *eeepc;
>
> eeepc = container_of(work, struct eeepc_laptop, tpd_led_work);
> diff --git a/drivers/rtc/rtc-ab-b5ze-s3.c b/drivers/rtc/rtc-ab-b5ze-s3.c
> index a319bf1e49de..ef5c16dfabfa 100644
> --- a/drivers/rtc/rtc-ab-b5ze-s3.c
> +++ b/drivers/rtc/rtc-ab-b5ze-s3.c
> @@ -648,7 +648,7 @@ static int abb5zes3_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
> ret);
>
> return ret;
> - }
> +}
>
> /* Enable or disable battery low irq generation */
> static inline int _abb5zes3_rtc_battery_low_irq_enable(struct regmap *regmap,
> diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
> index fd172b0890d3..a00d822e3142 100644
> --- a/drivers/scsi/dpt_i2o.c
> +++ b/drivers/scsi/dpt_i2o.c
> @@ -3524,7 +3524,7 @@ static int adpt_i2o_systab_send(adpt_hba* pHba)
> #endif
>
> return ret;
> - }
> +}
>
>
> /*============================================================================
> diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c
> index 791a2182de53..7320d5fe4cbc 100644
> --- a/drivers/scsi/sym53c8xx_2/sym_glue.c
> +++ b/drivers/scsi/sym53c8xx_2/sym_glue.c
> @@ -1393,7 +1393,7 @@ static struct Scsi_Host *sym_attach(struct scsi_host_template *tpnt, int unit,
> scsi_host_put(shost);
>
> return NULL;
> - }
> +}
>
>
> /*
> diff --git a/fs/locks.c b/fs/locks.c
> index 21b4dfa289ee..d2399d001afe 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -559,7 +559,7 @@ static const struct lock_manager_operations lease_manager_ops = {
> * Initialize a lease, use the default lock manager operations
> */
> static int lease_init(struct file *filp, long type, struct file_lock *fl)
> - {
> +{
> if (assign_type(fl, type) != 0)
> return -EINVAL;
>
> diff --git a/fs/ocfs2/stack_user.c b/fs/ocfs2/stack_user.c
> index dae9eb7c441e..d2fb97b173da 100644
> --- a/fs/ocfs2/stack_user.c
> +++ b/fs/ocfs2/stack_user.c
> @@ -398,7 +398,7 @@ static int ocfs2_control_do_setnode_msg(struct file *file,
>
> static int ocfs2_control_do_setversion_msg(struct file *file,
> struct ocfs2_control_message_setv *msg)
> - {
> +{
> long major, minor;
> char *ptr = NULL;
> struct ocfs2_control_private *p = file->private_data;
> diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c
> index 0da80019a917..217108f765d5 100644
> --- a/fs/xfs/libxfs/xfs_alloc.c
> +++ b/fs/xfs/libxfs/xfs_alloc.c
> @@ -2401,7 +2401,7 @@ static bool
> xfs_agf_verify(
> struct xfs_mount *mp,
> struct xfs_buf *bp)
> - {
> +{
> struct xfs_agf *agf = XFS_BUF_TO_AGF(bp);
>
> if (xfs_sb_version_hascrc(&mp->m_sb)) {
> @@ -2449,8 +2449,7 @@ xfs_agf_verify(
> be32_to_cpu(agf->agf_refcount_level) > XFS_BTREE_MAXLEVELS))
> return false;
>
> - return true;;
> -
> + return true;
> }
>
> static void
> diff --git a/fs/xfs/xfs_export.c b/fs/xfs/xfs_export.c
> index fe1bfee35898..7d5c355d78b5 100644
> --- a/fs/xfs/xfs_export.c
> +++ b/fs/xfs/xfs_export.c
> @@ -122,7 +122,7 @@ xfs_nfs_get_inode(
> struct super_block *sb,
> u64 ino,
> u32 generation)
> - {
> +{
> xfs_mount_t *mp = XFS_M(sb);
> xfs_inode_t *ip;
> int error;
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 227db99b0f19..d97e8f0f73ca 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -443,15 +443,15 @@ static int audit_set_failure(u32 state)
> * Drop any references inside the auditd connection tracking struct and free
> * the memory.
> */
> - static void auditd_conn_free(struct rcu_head *rcu)
> - {
> +static void auditd_conn_free(struct rcu_head *rcu)
> +{
> struct auditd_connection *ac;
>
> ac = container_of(rcu, struct auditd_connection, rcu);
> put_pid(ac->pid);
> put_net(ac->net);
> kfree(ac);
> - }
> +}
>
> /**
> * auditd_set - Set/Reset the auditd connection state
> diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c
> index ad1d6164e946..50f44b7b2b32 100644
> --- a/kernel/trace/trace_printk.c
> +++ b/kernel/trace/trace_printk.c
> @@ -196,7 +196,7 @@ struct notifier_block module_trace_bprintk_format_nb = {
> };
>
> int __trace_bprintk(unsigned long ip, const char *fmt, ...)
> - {
> +{
> int ret;
> va_list ap;
>
> @@ -214,7 +214,7 @@ int __trace_bprintk(unsigned long ip, const char *fmt, ...)
> EXPORT_SYMBOL_GPL(__trace_bprintk);
>
> int __ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap)
> - {
> +{
> if (unlikely(!fmt))
> return 0;
>
> diff --git a/lib/raid6/sse2.c b/lib/raid6/sse2.c
> index 1d2276b007ee..8191e1d0d2fb 100644
> --- a/lib/raid6/sse2.c
> +++ b/lib/raid6/sse2.c
> @@ -91,7 +91,7 @@ static void raid6_sse21_gen_syndrome(int disks, size_t bytes, void **ptrs)
>
> static void raid6_sse21_xor_syndrome(int disks, int start, int stop,
> size_t bytes, void **ptrs)
> - {
> +{
> u8 **dptr = (u8 **)ptrs;
> u8 *p, *q;
> int d, z, z0;
> @@ -200,9 +200,9 @@ static void raid6_sse22_gen_syndrome(int disks, size_t bytes, void **ptrs)
> kernel_fpu_end();
> }
>
> - static void raid6_sse22_xor_syndrome(int disks, int start, int stop,
> +static void raid6_sse22_xor_syndrome(int disks, int start, int stop,
> size_t bytes, void **ptrs)
> - {
> +{
> u8 **dptr = (u8 **)ptrs;
> u8 *p, *q;
> int d, z, z0;
> @@ -265,7 +265,7 @@ static void raid6_sse22_gen_syndrome(int disks, size_t bytes, void **ptrs)
>
> asm volatile("sfence" : : : "memory");
> kernel_fpu_end();
> - }
> +}
>
> const struct raid6_calls raid6_sse2x2 = {
> raid6_sse22_gen_syndrome,
> @@ -366,9 +366,9 @@ static void raid6_sse24_gen_syndrome(int disks, size_t bytes, void **ptrs)
> kernel_fpu_end();
> }
>
> - static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
> +static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
> size_t bytes, void **ptrs)
> - {
> +{
> u8 **dptr = (u8 **)ptrs;
> u8 *p, *q;
> int d, z, z0;
> @@ -471,7 +471,7 @@ static void raid6_sse24_gen_syndrome(int disks, size_t bytes, void **ptrs)
> }
> asm volatile("sfence" : : : "memory");
> kernel_fpu_end();
> - }
> +}
>
>
> const struct raid6_calls raid6_sse2x4 = {
> diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> index 0c11f434a374..ec619f51d336 100644
> --- a/sound/soc/fsl/fsl_dma.c
> +++ b/sound/soc/fsl/fsl_dma.c
> @@ -879,7 +879,7 @@ static const struct snd_pcm_ops fsl_dma_ops = {
> };
>
> static int fsl_soc_dma_probe(struct platform_device *pdev)
> - {
> +{
> struct dma_object *dma;
> struct device_node *np = pdev->dev.of_node;
> struct device_node *ssi_np;
>
> --
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
for the ACPI part.
Thanks!
^ permalink raw reply
* Re: [net 1/1] tipc: remove leaving group member from all lists
From: David Miller @ 2017-12-18 18:17 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1513617214-15464-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 18 Dec 2017 18:13:34 +0100
> A group member going into state LEAVING should never go back to any
> other state before it is finally deleted. However, this might happen
> if the socket needs to send out a RECLAIM message during this interval.
> Since we forget to remove the leaving member from the group's 'active'
> or 'pending' list, the member might be selected for reclaiming, change
> state to RECLAIMING, and get stuck in this state instead of being
> deleted. This might lead to suppression of the expected 'member down'
> event to the receiver.
>
> We fix this by removing the member from all lists, except the RB tree,
> at the moment it goes into state LEAVING.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Also applied, thanks Jon.
^ permalink raw reply
* Re: [net 1/1] tipc: fix lost member events bug
From: David Miller @ 2017-12-18 18:17 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1513614856-9857-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 18 Dec 2017 17:34:16 +0100
> Group messages are not supposed to be returned to sender when the
> destination socket disappears. This is done correctly for regular
> traffic messages, by setting the 'dest_droppable' bit in the header.
> But we forget to do that in group protocol messages. This has the effect
> that such messages may sometimes bounce back to the sender, be perceived
> as a legitimate peer message, and wreak general havoc for the rest of
> the session. In particular, we have seen that a member in state LEAVING
> may go back to state RECLAIMED or REMITTED, hence causing suppression
> of an otherwise expected 'member down' event to the user.
>
> We fix this by setting the 'dest_droppable' bit even in group protocol
> messages.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/6] sfc: Initial X2000-series (Medford2) support
From: David Miller @ 2017-12-18 18:16 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, netdev
In-Reply-To: <f9e1279b-03d0-729c-2518-c1e204444447@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Mon, 18 Dec 2017 16:54:29 +0000
> Basic PCI-level changes to support X2000-series NICs.
> Also fix unexpected-PTP-event log messages, since the timestamp format has
> been changed in these NICs and that causes us to fail to probe PTP (but we
> still get the PPS events).
Series applied.
^ permalink raw reply
* [PATCH net-next] bpf/cgroup: fix a verification error for a CGROUP_DEVICE type prog
From: Yonghong Song @ 2017-12-18 18:13 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: guro, kernel-team
The tools/testing/selftests/bpf test program
test_dev_cgroup fails with the following error
when compiled with llvm 6.0. (I did not try
with earlier versions.)
libbpf: load bpf program failed: Permission denied
libbpf: -- BEGIN DUMP LOG ---
libbpf:
0: (61) r2 = *(u32 *)(r1 +4)
1: (b7) r0 = 0
2: (55) if r2 != 0x1 goto pc+8
R0=inv0 R1=ctx(id=0,off=0,imm=0) R2=inv1 R10=fp0
3: (69) r2 = *(u16 *)(r1 +0)
invalid bpf_context access off=0 size=2
...
The culprit is the following statement in dev_cgroup.c:
short type = ctx->access_type & 0xFFFF;
This code is typical as the ctx->access_type is assigned
as below in kernel/bpf/cgroup.c:
struct bpf_cgroup_dev_ctx ctx = {
.access_type = (access << 16) | dev_type,
.major = major,
.minor = minor,
};
The compiler converts it to u16 access while
the verifier cgroup_dev_is_valid_access rejects
any non u32 access.
This patch permits the field access_type to be accessible
with type u16 and u8 as well.
Signed-off-by: Yonghong Song <yhs@fb.com>
Tested-by: Roman Gushchin <guro@fb.com>
---
include/uapi/linux/bpf.h | 3 ++-
kernel/bpf/cgroup.c | 15 +++++++++++++--
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 80d62e8..6aa60d4 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1001,7 +1001,8 @@ struct bpf_perf_event_value {
#define BPF_DEVCG_DEV_CHAR (1ULL << 1)
struct bpf_cgroup_dev_ctx {
- __u32 access_type; /* (access << 16) | type */
+ /* access_type encoded as (BPF_DEVCG_ACC_* << 16) | BPF_DEVCG_DEV_* */
+ __u32 access_type;
__u32 major;
__u32 minor;
};
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index b789ab7..c1c0b60 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -568,6 +568,8 @@ static bool cgroup_dev_is_valid_access(int off, int size,
enum bpf_access_type type,
struct bpf_insn_access_aux *info)
{
+ const int size_default = sizeof(__u32);
+
if (type == BPF_WRITE)
return false;
@@ -576,8 +578,17 @@ static bool cgroup_dev_is_valid_access(int off, int size,
/* The verifier guarantees that size > 0. */
if (off % size != 0)
return false;
- if (size != sizeof(__u32))
- return false;
+
+ switch (off) {
+ case bpf_ctx_range(struct bpf_cgroup_dev_ctx, access_type):
+ bpf_ctx_record_field_size(info, size_default);
+ if (!bpf_ctx_narrow_access_ok(off, size, size_default))
+ return false;
+ break;
+ default:
+ if (size != size_default)
+ return false;
+ }
return true;
}
--
2.9.5
^ permalink raw reply related
* [PATCH bpf-next] bpf: arm64: fix uninitialized variable
From: Alexei Starovoitov @ 2017-12-18 18:09 UTC (permalink / raw)
To: David S . Miller; +Cc: Daniel Borkmann, Arnd Bergmann, netdev, kernel-team
From: Alexei Starovoitov <ast@fb.com>
fix the following issue:
arch/arm64/net/bpf_jit_comp.c: In function 'bpf_int_jit_compile':
arch/arm64/net/bpf_jit_comp.c:982:18: error: 'image_size' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
Fixes: db496944fdaa ("bpf: arm64: add JIT support for multi-function programs")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
arch/arm64/net/bpf_jit_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 396490cf7316..acaa935ed977 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -897,6 +897,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
image_ptr = jit_data->image;
header = jit_data->header;
extra_pass = true;
+ image_size = sizeof(u32) * ctx.idx;
goto skip_init_ctx;
}
memset(&ctx, 0, sizeof(ctx));
--
2.9.5
^ permalink raw reply related
* Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
From: Bart Van Assche @ 2017-12-18 17:56 UTC (permalink / raw)
To: joe@perches.com, jgg@ziepe.ca
Cc: corbet@lwn.net, linux-kernel@vger.kernel.org,
keescook@chromium.org, linux-rdma@vger.kernel.org,
linux-doc@vger.kernel.org, willy@infradead.org,
knut.omang@oracle.com, nicolas.palix@imag.fr,
asmund.ostvold@oracle.com, john.haxby@oracle.com,
alexander.levin@verizon.com, mchehab@kernel.org,
haakon.bugge@oracle.com, michal.lkml@markovi.net,
Gilles.Muller@lip6.fr, "yama
In-Reply-To: <20171218174604.GA19056@ziepe.ca>
On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
>
> > > Today when we run checkers we get so many warnings it is too hard to
> > > make any sense of it.
> >
> > Here is a list of the checkpatch messages for drivers/infiniband
> > sorted by type.
> >
> > Many of these might be corrected by using
> >
> > $ ./scripts/checkpatch.pl -f --fix-inplace --types=<TYPE> \
> > $(git ls-files drivers/infiniband/)
>
> How many of these do you think it is worth to fix?
>
> We do get a steady trickle of changes in this topic every cycle.
>
> Is it better to just do a big number of them all at once? Do you have
> an idea how disruptive this kind of work is to the whole patch flow
> eg new patches no longer applying to for-next, backports no longer
> applying, merge conflicts?
In my opinion patches that only change the coding style and do not change any
functionality are annoying. Before posting a patch that fixes a bug the change
history (git log -p) has to be cheched to figure out which patch introduced
the bug. Patches that only change coding style pollute the change history.
Bart.
^ permalink raw reply
* Re: [RFC ipsec-next 3/4] net: xfrm: support multiple VTI tunnels
From: David Miller @ 2017-12-18 17:56 UTC (permalink / raw)
To: lorenzo; +Cc: netdev, steffen.klassert, subashab, nharold
In-Reply-To: <20171218161656.40618-4-lorenzo@google.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 19 Dec 2017 01:16:55 +0900
> - ICMP errors are similar to input, except the search is for the
> outbound XFRM state, because the only data that is available is
> the outbound SPI. Thus, ICMP errors are only processed if the
> ikey is the same as the same as the okey. AFAICS this is
> consistent with GRE tunnels, but not with existing VTI
> behaviour.
I think you will need to sort out the VTI ICMP behavior difference
with what exists now.
^ permalink raw reply
* Re: [PATCH bpf-next 12/13] bpf: arm64: add JIT support for multi-function programs
From: Alexei Starovoitov @ 2017-12-18 17:55 UTC (permalink / raw)
To: Daniel Borkmann, Arnd Bergmann, Alexei Starovoitov
Cc: David S . Miller, John Fastabend, Edward Cree, Jakub Kicinski,
Networking, kernel-team
In-Reply-To: <90da62d9-830e-4ea7-b542-ac7a2eb0a811@iogearbox.net>
On 12/18/17 7:51 AM, Daniel Borkmann wrote:
> On 12/18/2017 04:29 PM, Arnd Bergmann wrote:
>> On Fri, Dec 15, 2017 at 2:55 AM, Alexei Starovoitov <ast@kernel.org> wrote:
>>
>>
>>> + if (jit_data->ctx.offset) {
>>> + ctx = jit_data->ctx;
>>> + image_ptr = jit_data->image;
>>> + header = jit_data->header;
>>> + extra_pass = true;
>>> + goto skip_init_ctx;
>>> + }
>>> memset(&ctx, 0, sizeof(ctx));
>>> ctx.prog = prog;
>>
>> The 'goto' jumps over the 'image_size' initialization
>>
>>> prog->bpf_func = (void *)ctx.image;
>>> prog->jited = 1;
>>> prog->jited_len = image_size;
>>
>> so we now get a warning here, starting with linux-next-20171218:
>>
>> arch/arm64/net/bpf_jit_comp.c: In function 'bpf_int_jit_compile':
>> arch/arm64/net/bpf_jit_comp.c:982:18: error: 'image_size' may be used
>> uninitialized in this function [-Werror=maybe-uninitialized]
>>
>> I could not figure out what the code should be doing instead, or if it is
>> indeed safe and the warning is a false-positive.
>
> Good catch, it's buggy indeed. Fix like below is needed; I can submit
> it properly a bit later today:
good catch. My arm gcc 4.8.5 didn't warn about it.
the following would be better fix:
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 396490cf7316..acaa935ed977 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -897,6 +897,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog
*prog)
image_ptr = jit_data->image;
header = jit_data->header;
extra_pass = true;
+ image_size = sizeof(u32) * ctx.idx;
goto skip_init_ctx;
}
memset(&ctx, 0, sizeof(ctx));
> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
> index 396490c..a6fd585 100644
> --- a/arch/arm64/net/bpf_jit_comp.c
> +++ b/arch/arm64/net/bpf_jit_comp.c
> @@ -855,6 +855,7 @@ static inline void bpf_flush_icache(void *start, void *end)
> struct arm64_jit_data {
> struct bpf_binary_header *header;
> u8 *image;
> + int image_size;
> struct jit_ctx ctx;
> };
>
> @@ -895,6 +896,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> if (jit_data->ctx.offset) {
> ctx = jit_data->ctx;
> image_ptr = jit_data->image;
> + image_size = jit_data->image_size;
> header = jit_data->header;
> extra_pass = true;
> goto skip_init_ctx;
> @@ -975,6 +977,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> } else {
> jit_data->ctx = ctx;
> jit_data->image = image_ptr;
> + jit_data->image_size = image_size;
> jit_data->header = header;
> }
> prog->bpf_func = (void *)ctx.image;
>
^ permalink raw reply related
* Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
From: Joe Perches @ 2017-12-18 17:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Knut Omang, Stephen Hemminger, linux-kernel,
Mauro Carvalho Chehab, Nicolas Palix, Jonathan Corbet,
Santosh Shilimkar, Matthew Wilcox, cocci, rds-devel, linux-rdma,
linux-doc, Doug Ledford, Mickaël Salaün, Shuah Khan,
linux-kbuild, Michal Marek, Julia Lawall, John Haxby,
Åsmund Østvold
In-Reply-To: <20171218174604.GA19056@ziepe.ca>
On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
>
> > > Today when we run checkers we get so many warnings it is too hard to
> > > make any sense of it.
> >
> > Here is a list of the checkpatch messages for drivers/infiniband
> > sorted by type.
> >
> > Many of these might be corrected by using
> >
> > $ ./scripts/checkpatch.pl -f --fix-inplace --types=<TYPE> \
> > $(git ls-files drivers/infiniband/)
>
> How many of these do you think it is worth to fix?
>
> We do get a steady trickle of changes in this topic every cycle.
>
> Is it better to just do a big number of them all at once?
I think so.
> Do you have
> an idea how disruptive this kind of work is to the whole patch flow
> eg new patches no longer applying to for-next, backports no longer
> applying, merge conflicts?
Some do complain about backport patch purity.
I think that difficulty is overstated, but then
again, I don't do backports very often.
I think the best time for any rather wholesale
change is immediately after an rc-1 so overall
in-flight patch conflict volume is minimized.
^ permalink raw reply
* [PATCH] ss: fix crash with invalid command input file
From: Stephen Hemminger @ 2017-12-18 17:52 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Stephen Hemminger
If given an invalid input file with -F flag, ss would crash.
Examples of invalid input are line to long, or null file.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
misc/ssfilter.y | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/misc/ssfilter.y b/misc/ssfilter.y
index ba82b65f712b..4db3c95faa3c 100644
--- a/misc/ssfilter.y
+++ b/misc/ssfilter.y
@@ -202,15 +202,23 @@ int yylex(void)
argc++;
} else if (yy_fp) {
while (tokptr == NULL) {
- if (fgets(argbuf, sizeof(argbuf)-1, yy_fp) == NULL)
+ size_t len;
+
+ if (fgets(argbuf, sizeof(argbuf), yy_fp) == NULL)
return 0;
- argbuf[sizeof(argbuf)-1] = 0;
- if (strlen(argbuf) == sizeof(argbuf) - 1) {
- fprintf(stderr, "Too long line in filter");
+
+ len = strnlen(argbuf, sizeof(argbuf));
+ if (len == 0) {
+ fprintf(stderr, "Invalid line\n");
+ exit(-1);
+ }
+
+ if (len >= sizeof(argbuf) - 1) {
+ fprintf(stderr, "Too long line in filter\n");
exit(-1);
}
- if (argbuf[strlen(argbuf)-1] == '\n')
- argbuf[strlen(argbuf)-1] = 0;
+ if (argbuf[len - 1] == '\n')
+ argbuf[len-1] = 0;
if (argbuf[0] == '#' || argbuf[0] == '0')
continue;
tokptr = argbuf;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
From: Jason Gunthorpe @ 2017-12-18 17:49 UTC (permalink / raw)
To: Knut Omang
Cc: Joe Perches, Stephen Hemminger,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mauro Carvalho Chehab,
Nicolas Palix, Jonathan Corbet, Santosh Shilimkar, Matthew Wilcox,
cocci-/FJkirnvOdkvYVN+rsErww, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Doug Ledford,
Mickaël Salaün, Shuah Khan,
linux-kbuild-u79uwXL29TY76Z2rM5mHXA, Michal Marek, Julia Lawall,
John Haxby, Åsmund Østvold
In-Reply-To: <1513602315.22938.49.camel-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Mon, Dec 18, 2017 at 02:05:15PM +0100, Knut Omang wrote:
> https://github.com/torvalds/linux/compare/master...knuto:runchecks
Several of these to rdma/core do not look so big, you should think
about sending them..
Jason
--
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
* [PATCH iproute2 3/3] link_vti6: Always add local/remote endpoint attributes
From: Serhey Popovych @ 2017-12-18 17:48 UTC (permalink / raw)
To: netdev
In-Reply-To: <1513619285-23187-1-git-send-email-serhe.popovych@gmail.com>
All tunnels already support for parsing/adding zero
endpoints and vti6 isn't an exception.
This check was added as part of commit 2a80154fde40
(vti6: fix local/remote any addr handling) and looks
too restrictive as purpose of change is to avoid
endpoint configuration from uninitialized data.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/link_vti6.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/ip/link_vti6.c b/ip/link_vti6.c
index f631839..4136b0e 100644
--- a/ip/link_vti6.c
+++ b/ip/link_vti6.c
@@ -154,10 +154,8 @@ get_failed:
addattr32(n, 1024, IFLA_VTI_IKEY, ikey);
addattr32(n, 1024, IFLA_VTI_OKEY, okey);
- if (memcmp(&saddr, &in6addr_any, sizeof(in6addr_any)))
- addattr_l(n, 1024, IFLA_VTI_LOCAL, &saddr, sizeof(saddr));
- if (memcmp(&daddr, &in6addr_any, sizeof(in6addr_any)))
- addattr_l(n, 1024, IFLA_VTI_REMOTE, &daddr, sizeof(daddr));
+ addattr_l(n, 1024, IFLA_VTI_LOCAL, &saddr, sizeof(saddr));
+ addattr_l(n, 1024, IFLA_VTI_REMOTE, &daddr, sizeof(daddr));
addattr32(n, 1024, IFLA_VTI_FWMARK, fwmark);
if (link)
addattr32(n, 1024, IFLA_VTI_LINK, link);
--
1.7.10.4
^ 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