* Re: [PATCH] rsi: fix integer overflow warning
From: Joe Perches @ 2017-10-05 12:19 UTC (permalink / raw)
To: Arnd Bergmann, Kalle Valo, Prameela Rani Garnepudi,
Amitkumar Karwar
Cc: Pavani Muthyala, Karun Eagalapati, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20171005120547.328687-1-arnd@arndb.de>
On Thu, 2017-10-05 at 14:05 +0200, Arnd Bergmann wrote:
> gcc produces a harmless warning about a recently introduced
> signed integer overflow:
>
> drivers/net/wireless/rsi/rsi_91x_hal.c: In function 'rsi_prepare_mgmt_desc':
> include/uapi/linux/swab.h:13:15: error: integer overflow in expression [-Werror=overflow]
> (((__u16)(x) & (__u16)0x00ffU) << 8) | \
> ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
> include/uapi/linux/swab.h:104:2: note: in expansion of macro '___constant_swab16'
> ___constant_swab16(x) : \
> ^~~~~~~~~~~~~~~~~~
> include/uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro '__swab16'
> #define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
[]
> The problem is that the 'mask' value is a signed integer that gets
> turned into a negative number when truncated to 16 bits. Making it
> an unsigned constant avoids this.
I would expect there are more of these.
Perhaps this define in include/uapi/linux/swab.h:
#define __swab16(x) \
(__builtin_constant_p((__u16)(x)) ? \
___constant_swab16(x) : \
__fswab16(x))
should be
#define __swab16(x) \
(__builtin_c
onstant_p((__u16)(x)) ? \
___constant_swab16((__u16)(x)) :
\
__fswab16((__u16)(x)))
^ permalink raw reply
* Apply
From: Capital Finance @ 2017-10-05 12:23 UTC (permalink / raw)
To: Recipients
UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE
- NO COLLATERAL
- MINIMUM DOCUMENTATION
- BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS
CONTACT US TODAY VIA EMAIL: financeloan04@hotmail.com
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] net/sched: support tunnel options in cls_flower and act_tunnel_key
From: Jiri Benc @ 2017-10-05 12:51 UTC (permalink / raw)
To: Simon Horman; +Cc: David Miller, jiri, jhs, xiyou.wangcong, netdev, oss-drivers
In-Reply-To: <20171002075013.GA22179@netronome.com>
On Mon, 2 Oct 2017 09:50:15 +0200, Simon Horman wrote:
> I believe that in order to avoid per-packet overhead and at the same time
> code complexity the TLVs should be described in-order. So matching on
> TLV-A,TLV-B,TLV-C would be a different match to TLV-C,TLV-A,TLV-B. An
> order-independent match could be added if desired in future.
Although better than the binary format, I doubt that it would be
useful. I can't imagine a real use case where you would want such match.
Instead, what you want is a match on a particular TLV, wherever it is
in the data. For start, we can support just a single TLV.
I.e. when matching on TLV-A, all of these would match:
TLV-A,TLV-B,TLV-C; TLV-B,TLV-A,TLV-C; TLV-B,TLV-C,TLV-A. And this one
won't match: TLV-B,TLV-C,TLV-D.
Jiri
^ permalink raw reply
* Re: [patch net-next 1/6] net: bridge: Use the MDB_RTR_TYPE_TEMP on bridge device too
From: Nikolay Aleksandrov @ 2017-10-05 12:52 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, yotamg, idosch, nogahf, mlxsw, ivecera, andrew, stephen,
nbd, roopa
In-Reply-To: <b9cfcf9f-bb3a-6649-5b6a-39be0a957550@cumulusnetworks.com>
On 05/10/17 15:09, Nikolay Aleksandrov wrote:
> On 05/10/17 13:36, Jiri Pirko wrote:
>> From: Yotam Gigi <yotamg@mellanox.com>
>>
>> Every bridge port is in one of four mcast router port states:
>> - MDB_RTR_TYPE_PERM - the port is set by the user to be an mrouter port
>> regardless of IGMP queries.
>> - MDB_RTR_TYPE_DISABLED - the port is set by the user to not be an mrouter
>> port regardless of IGMP queries.
>> - MDB_RTR_TYPE_TEMP - the port is set by the user to be in mcast router
>> learning state, but currently it is not an mrouter port as no IGMP query
>> has been received by it for the last multicast_querier_interval.
>> - MDB_RTR_TYPE_TEMP_QUERY - the port is set by the user to be in mcast
>> router learning state, and currently it is an mrouter port due to an
>> IGMP query that has been received by it during the passed
>> multicast_querier_interval.
>
> I think you got the last two partially mixed up, MDB_RTR_TYPE_TEMP marks the port as a router
> regardless if there were any igmp queries, while TYPE_TEMP_QUERY means it's in learning
> state. It is the timer (armed vs not) that defines if currently the port is a router
> when one of the TEMP/TEMP_QUERY are set. In the _TEMP case it is always armed as it
> is refreshed by user or igmp queries which was the point of that mode.
> So this means in br_multicast_router() just check for the timer_pending or perm mode.
>
> In the port code you have the following transitions:
> _TEMP -> TEMP_QUERY (on timer fire or user-set val, port becomes learning only)
> _TEMP -> _TEMP (noop on user refresh or igmp query, timer refreshes)
> _TEMP_QUERY -> _TEMP_QUERY (on igmp query the timer is armed, port becomes router)
>
> you never have _TEMP_QUERY -> _TEMP, which you're using here to denote the timer
> getting armed and the bridge becoming a router.
>
>>
>> The bridge device (brX) itself can also be configured by the user to be
>> either fixed, disabled or learning mrouter port states, but currently there
>> is no distinction between the MDB_RTR_TYPE_TEMP_QUERY and MDB_RTR_TYPE_TEMP
>> in the bridge internal state. Due to that, when an IGMP query is received,
>> it is not straightforward to tell whether it changes the bridge device
>> mrouter port status or not.
>
> But before this patch the bridge device could not get that set.
>
>>
>> Further patches in this patch-set will introduce notifications upon the
>> bridge device mrouter port state. In order to prevent resending bridge
>> mrouter notification when it is not needed, such distinction is necessary.
>>
>
> Granted the bridge device hasn't got a way to clearly distinguish the transitions
> without the chance for a race and if using the timer one could get an unnecessary
> notification but that seems like a corner case when the timer fires exactly at the
> same time as the igmp query is received. Can't it be handled by just checking if
> the new state is different in the notification receiver ?
Scratch the sentence below, on a second thought I'd prefer to stick with this
version if it's a problem. :-)
> If it can't and is a problem then I'd prefer to add a new boolean to denote that
> router on/off transition rather than doing this.
>
>> Hence, add the distinction between MDB_RTR_TYPE_TEMP and
>> MDB_RTR_TYPE_TEMP_QUERY states for the bridge device, similarly to any
>> other bridge port.
>>
>
> This does not add proper MDB_RTR_TYPE_TEMP support for the bridge device
> but seems to abuse it to distinguish the timer state, and changes
> the meaning of MDB_RTR_TYPE_TEMP. Can't you just use the timer instead ?
> I think it will simplify the set and avoid all of this.
>
>> In order to not break the current kernel-user API, don't propagate the new
>> state to the user and use it only in the bridge internal state. Thus, if
>> the user reads (either via sysfs or netlink) the bridge device mrouter
>> state, he will get the MDB_RTR_TYPE_TEMP_QUERY state even if the current
>> bridge state is MDB_RTR_TYPE_TEMP.
>>
[snip]
^ permalink raw reply
* [PATCH net] selftests/net: rxtimestamp: Fix an off by one
From: Dan Carpenter @ 2017-10-05 12:53 UTC (permalink / raw)
To: Shuah Khan, Mike Maloney
Cc: Willem de Bruijn, David S. Miller, linux-kselftest, netdev,
kernel-janitors
The > should be >= so that we don't write one element beyond the end of
the array.
Fixes: 16e781224198 ("selftests/net: Add a test to validate behavior of rx timestamps")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/tools/testing/selftests/networking/timestamping/rxtimestamp.c b/tools/testing/selftests/networking/timestamping/rxtimestamp.c
index 00f286661dcd..dd4162fc0419 100644
--- a/tools/testing/selftests/networking/timestamping/rxtimestamp.c
+++ b/tools/testing/selftests/networking/timestamping/rxtimestamp.c
@@ -341,7 +341,7 @@ int main(int argc, char **argv)
return 0;
case 'n':
t = atoi(optarg);
- if (t > ARRAY_SIZE(test_cases))
+ if (t >= ARRAY_SIZE(test_cases))
error(1, 0, "Invalid test case: %d", t);
all_tests = false;
test_cases[t].enabled = true;
^ permalink raw reply related
* [PATCH 3/3] xen/9pfs: don't inclide rwlock.h directly.
From: Sebastian Andrzej Siewior @ 2017-10-05 12:56 UTC (permalink / raw)
To: linux-kernel
Cc: tglx, Sebastian Andrzej Siewior, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, David S. Miller, v9fs-developer, netdev
In-Reply-To: <20171005125655.12373-1-bigeasy@linutronix.de>
rwlock.h should not be included directly. Instead linux/splinlock.h
should be included. One thing it does is to break the RT build.
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Ron Minnich <rminnich@sandia.gov>
Cc: Latchesar Ionkov <lucho@ionkov.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: v9fs-developer@lists.sourceforge.net
Cc: netdev@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
net/9p/trans_xen.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 6ad3e043c617..02c6c467a99c 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -38,7 +38,6 @@
#include <linux/module.h>
#include <linux/spinlock.h>
-#include <linux/rwlock.h>
#include <net/9p/9p.h>
#include <net/9p/client.h>
#include <net/9p/transport.h>
--
2.14.2
^ permalink raw reply related
* Re: [patch net-next 3/6] net: bridge: Export bridge multicast router state
From: Nikolay Aleksandrov @ 2017-10-05 13:09 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, yotamg, idosch, nogahf, mlxsw, ivecera, andrew, stephen,
nbd, roopa
In-Reply-To: <20171005103642.1414-4-jiri@resnulli.us>
On 05/10/17 13:36, Jiri Pirko wrote:
> From: Yotam Gigi <yotamg@mellanox.com>
>
> Add an access function that, given a bridge netdevice, returns whether the
> bridge device is currently an mrouter or not. The function uses the already
> existing br_multicast_is_router function to check that.
>
> This function is needed in order to allow ports that join an already
> existing bridge to know the current mrouter state of the bridge device.
> Together with the bridge device mrouter ports switchdev notifications, it
> is possible to have full offloading of the semantics of the bridge device
> mcast router state.
>
> Due to the fact that the bridge multicast router status can change in
> packet RX path, take the multicast_router bridge spinlock to protect the
> read.
>
> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
> Reviewed-by: Nogah Frankel <nogahf@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> include/linux/if_bridge.h | 5 +++++
> net/bridge/br_multicast.c | 12 ++++++++++++
> 2 files changed, 17 insertions(+)
>
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [patch net-next 2/6] net: bridge: Notify on bridge device mrouter state changes
From: Nikolay Aleksandrov @ 2017-10-05 13:11 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, yotamg, idosch, nogahf, mlxsw, ivecera, andrew, stephen,
nbd, roopa
In-Reply-To: <20171005103642.1414-3-jiri@resnulli.us>
On 05/10/17 13:36, Jiri Pirko wrote:
> From: Yotam Gigi <yotamg@mellanox.com>
>
> Add the SWITCHDEV_ATTR_ID_BRIDGE_MROUTER switchdev notification type, used
> to indicate whether the bridge is or isn't mrouter. Notify when the bridge
> changes its state, similarly to the already existing bridged port mrouter
> notifications.
>
> The notification uses the switchdev_attr.u.mrouter boolean flag to indicate
> the current bridge mrouter status. Thus, it only indicates whether the
> bridge is currently used as an mrouter or not, and does not indicate the
> exact mrouter state of the bridge (learning, permanent, etc.).
>
> Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
> Reviewed-by: Nogah Frankel <nogahf@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> include/net/switchdev.h | 1 +
> net/bridge/br_multicast.c | 21 ++++++++++++++++++++-
> 2 files changed, 21 insertions(+), 1 deletion(-)
>
LGTM, but if we switch to using the timer state it will need some adjustment.
Anyway for this version,
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned
From: Herbert Xu @ 2017-10-05 13:16 UTC (permalink / raw)
To: David Miller
Cc: marcelo.leitner-Re5JQEeQqe8AvxtiuMwx3w,
luto-DgEjT+Ai2ygdnm+yROfE0A, baijiaju1990-9Onoh4P/yGk,
nhorman-2XuSBdqkA4R54TAoqtyWWQ, vyasevich-Re5JQEeQqe8AvxtiuMwx3w,
kvalo-sgV2jX0FEOL9JmXXK+q4OQ, linux-crypto-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-sctp-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171005101620.GA1246-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On Thu, Oct 05, 2017 at 06:16:20PM +0800, Herbert Xu wrote:
>
> That was my point. Functions like sctp_pack_cookie shouldn't be
> setting the key in the first place. The setkey should happen at
> the point when the key is generated. That's sctp_endpoint_init
> which AFAICS only gets called in GFP_KERNEL context.
>
> Or is there a code-path where sctp_endpoint_init is called in
> softirq context?
OK, there are indeed code paths where the key is derived in softirq
context. Notably sctp_auth_calculate_hmac.
So I think this patch is the correct fix and I will push it upstream
as well as back to stable.
Thanks,
--
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next 0/3] A own subdirectory for shared TCP code
From: Richard Siegfried @ 2017-10-05 13:17 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20171004202749.GB13247@lunn.ch>
[-- Attachment #1.1: Type: text/plain, Size: 539 bytes --]
On 04/10/17 22:27, Andrew Lunn wrote:
> Hi Richard
>
> It is generally unwanted.
>
> Have you tried back porting patches when the directory structure has
> changed? Files have moved around? It makes it a lot harder to
> do. Meaning patches are going to be back ported less often. Fixes
> which could be security relevant might not get back ported, etc.
>
> Kernel 4.4 is going to be supported until 2022. So moving files around
> is going to make Greg Kroah-Hartman life more difficult for the next 5
> years.
Ok, I see
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 529 bytes --]
^ permalink raw reply
* Re: [PATCH 03/13] timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack()
From: Rafael J. Wysocki @ 2017-10-05 13:18 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Rafael J. Wysocki, Pavel Machek, Len Brown,
Greg Kroah-Hartman, Stefan Richter, Sudip Mukherjee,
Martin Schwidefsky, Heiko Carstens, Julian Wiedmann, Ursula Braun,
Michael Reed, James E.J. Bottomley, Martin K. Petersen, Linux PM,
linux1394-devel, linux-s390, open list:TARGET SUBSYSTEM,
Andrew Morton
In-Reply-To: <1507159627-127660-4-git-send-email-keescook@chromium.org>
On Thu, Oct 5, 2017 at 1:26 AM, Kees Cook <keescook@chromium.org> wrote:
> Remove uses of init_timer_on_stack() with open-coded function and data
> assignments that could be expressed using timer_setup_on_stack(). Several
> were removed from the stack entirely since there was a one-to-one mapping
> of parent structure to timer, those are switched to using timer_setup()
> instead. All related callbacks were adjusted to use from_timer().
>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Len Brown <len.brown@intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Julian Wiedmann <jwi@linux.vnet.ibm.com>
> Cc: Ursula Braun <ubraun@linux.vnet.ibm.com>
> Cc: Michael Reed <mdr@sgi.com>
> Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
> Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: linux-pm@vger.kernel.org
> Cc: linux1394-devel@lists.sourceforge.net
> Cc: linux-s390@vger.kernel.org
> Cc: linux-scsi@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> drivers/base/power/main.c | 8 +++-----
> drivers/firewire/core-transaction.c | 10 +++++-----
> drivers/parport/ieee1284.c | 21 +++++++--------------
> drivers/s390/char/tape.h | 1 +
> drivers/s390/char/tape_std.c | 18 ++++++------------
> drivers/s390/net/lcs.c | 16 ++++++----------
> drivers/s390/net/lcs.h | 1 +
> drivers/scsi/qla1280.c | 14 +++++---------
> drivers/scsi/qla1280.h | 1 +
> include/linux/parport.h | 1 +
> include/linux/timer.h | 2 --
> 11 files changed, 36 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 770b1539a083..ae47b2ec84b4 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -478,9 +478,9 @@ struct dpm_watchdog {
> * There's not much we can do here to recover so panic() to
> * capture a crash-dump in pstore.
> */
> -static void dpm_watchdog_handler(unsigned long data)
> +static void dpm_watchdog_handler(struct timer_list *t)
> {
> - struct dpm_watchdog *wd = (void *)data;
> + struct dpm_watchdog *wd = from_timer(wd, t, timer);
>
> dev_emerg(wd->dev, "**** DPM device timeout ****\n");
> show_stack(wd->tsk, NULL);
> @@ -500,11 +500,9 @@ static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev)
> wd->dev = dev;
> wd->tsk = current;
>
> - init_timer_on_stack(timer);
> + timer_setup_on_stack(timer, dpm_watchdog_handler, 0);
> /* use same timeout value for both suspend and resume */
> timer->expires = jiffies + HZ * CONFIG_DPM_WATCHDOG_TIMEOUT;
> - timer->function = dpm_watchdog_handler;
> - timer->data = (unsigned long)wd;
> add_timer(timer);
> }
For the above:
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
^ permalink raw reply
* Re: [PATCH net-next 3/4] selinux: bpf: Add selinux check for eBPF syscall operations
From: Stephen Smalley @ 2017-10-05 13:28 UTC (permalink / raw)
To: Chenbo Feng, netdev, SELinux, linux-security-module
Cc: Chenbo Feng, Alexei Starovoitov, Daniel Borkmann, Lorenzo Colitti
In-Reply-To: <20171004182932.140028-4-chenbofeng.kernel@gmail.com>
On Wed, 2017-10-04 at 11:29 -0700, Chenbo Feng wrote:
> From: Chenbo Feng <fengc@google.com>
>
> Implement the actual checks introduced to eBPF related syscalls. This
> implementation use the security field inside bpf object to store a
> sid that
> identify the bpf object. And when processes try to access the object,
> selinux will check if processes have the right privileges. The
> creation
> of eBPF object are also checked at the general bpf check hook and new
> cmd introduced to eBPF domain can also be checked there.
>
> Signed-off-by: Chenbo Feng <fengc@google.com>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
> security/selinux/hooks.c | 111
> ++++++++++++++++++++++++++++++++++++
> security/selinux/include/classmap.h | 2 +
> security/selinux/include/objsec.h | 4 ++
> 3 files changed, 117 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index f5d304736852..41aba4e3d57c 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -85,6 +85,7 @@
> #include <linux/export.h>
> #include <linux/msg.h>
> #include <linux/shm.h>
> +#include <linux/bpf.h>
>
> #include "avc.h"
> #include "objsec.h"
> @@ -6252,6 +6253,106 @@ static void selinux_ib_free_security(void
> *ib_sec)
> }
> #endif
>
> +#ifdef CONFIG_BPF_SYSCALL
> +static int selinux_bpf(int cmd, union bpf_attr *attr,
> + unsigned int size)
> +{
> + u32 sid = current_sid();
> + int ret;
> +
> + switch (cmd) {
> + case BPF_MAP_CREATE:
> + ret = avc_has_perm(sid, sid, SECCLASS_BPF_MAP,
> BPF_MAP__CREATE,
> + NULL);
> + break;
> + case BPF_PROG_LOAD:
> + ret = avc_has_perm(sid, sid, SECCLASS_BPF_PROG,
> BPF_PROG__LOAD,
> + NULL);
> + break;
> + default:
> + ret = 0;
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static u32 bpf_map_fmode_to_av(fmode_t fmode)
> +{
> + u32 av = 0;
> +
> + if (f_mode & FMODE_READ)
> + av |= BPF_MAP__READ;
> + if (f_mode & FMODE_WRITE)
> + av |= BPF_MAP__WRITE;
> + return av;
> +}
> +
> +static int selinux_bpf_map(struct bpf_map *map, fmode_t fmode)
> +{
> + u32 sid = current_sid();
> + struct bpf_security_struct *bpfsec;
> +
> + bpfsec = map->security;
> + return avc_has_perm(sid, bpfsec->sid, SECCLASS_BPF_MAP,
> + bpf_map_fmode_to_av(fmode), NULL);
> +}
> +
> +static int selinux_bpf_prog(struct bpf_prog *prog)
> +{
> + u32 sid = current_sid();
> + struct bpf_security_struct *bpfsec;
> +
> + bpfsec = prog->aux->security;
I haven't looked closely at the bpf code, but is it guaranteed that
prog->aux cannot be NULL here? What's the difference in lifecycle for
bpf_prog vs bpf_prog_aux? Could the aux field be shared across progs
created by different processes?
> + return avc_has_perm(sid, bpfsec->sid, SECCLASS_BPF_PROG,
> + BPF_PROG__USE, NULL);
> +}
> +
> +static int selinux_bpf_map_alloc(struct bpf_map *map)
> +{
> + struct bpf_security_struct *bpfsec;
> +
> + bpfsec = kzalloc(sizeof(*bpfsec), GFP_KERNEL);
> + if (!bpfsec)
> + return -ENOMEM;
> +
> + bpfsec->sid = current_sid();
> + map->security = bpfsec;
> +
> + return 0;
> +}
> +
> +static void selinux_bpf_map_free(struct bpf_map *map)
> +{
> + struct bpf_security_struct *bpfsec = map->security;
> +
> + map->security = NULL;
> + kfree(bpfsec);
> +}
> +
> +static int selinux_bpf_prog_alloc(struct bpf_prog_aux *aux)
> +{
> + struct bpf_security_struct *bpfsec;
> +
> + bpfsec = kzalloc(sizeof(*bpfsec), GFP_KERNEL);
> + if (!bpfsec)
> + return -ENOMEM;
> +
> + bpfsec->sid = current_sid();
> + aux->security = bpfsec;
> +
> + return 0;
> +}
> +
> +static void selinux_bpf_prog_free(struct bpf_prog_aux *aux)
> +{
> + struct bpf_security_struct *bpfsec = aux->security;
> +
> + aux->security = NULL;
> + kfree(bpfsec);
> +}
> +#endif
> +
> static struct security_hook_list selinux_hooks[] __lsm_ro_after_init
> = {
> LSM_HOOK_INIT(binder_set_context_mgr,
> selinux_binder_set_context_mgr),
> LSM_HOOK_INIT(binder_transaction,
> selinux_binder_transaction),
> @@ -6471,6 +6572,16 @@ static struct security_hook_list
> selinux_hooks[] __lsm_ro_after_init = {
> LSM_HOOK_INIT(audit_rule_match, selinux_audit_rule_match),
> LSM_HOOK_INIT(audit_rule_free, selinux_audit_rule_free),
> #endif
> +
> +#ifdef CONFIG_BPF_SYSCALL
> + LSM_HOOK_INIT(bpf, selinux_bpf),
> + LSM_HOOK_INIT(bpf_map, selinux_bpf_map),
> + LSM_HOOK_INIT(bpf_prog, selinux_bpf_prog),
> + LSM_HOOK_INIT(bpf_map_alloc_security,
> selinux_bpf_map_alloc),
> + LSM_HOOK_INIT(bpf_prog_alloc_security,
> selinux_bpf_prog_alloc),
> + LSM_HOOK_INIT(bpf_map_free_security, selinux_bpf_map_free),
> + LSM_HOOK_INIT(bpf_prog_free_security,
> selinux_bpf_prog_free),
> +#endif
> };
>
> static __init int selinux_init(void)
> diff --git a/security/selinux/include/classmap.h
> b/security/selinux/include/classmap.h
> index 35ffb29a69cb..7253c5eea59c 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -237,6 +237,8 @@ struct security_class_mapping secclass_map[] = {
> { "access", NULL } },
> { "infiniband_endport",
> { "manage_subnet", NULL } },
> + { "bpf_map", {"create", "read", "write"} },
> + { "bpf_prog", {"load", "use"} },
Alternatively, assuming that one usually allows access to bpf_map and
bpf_prog together, these could be coalesced into a single class and
only distinguish by permission, e.g.
{ "bpf", { "create_map", "read_map", "write_map", "prog_load",
"prog_use" } },
and then allow A self:bpf { create_map read_map write_map prog_load
prog_use }; would be stored in a single policy avtab rule, and be
cached in a single AVC entry.
> { NULL }
> };
>
> diff --git a/security/selinux/include/objsec.h
> b/security/selinux/include/objsec.h
> index 1649cd18eb0b..3d54468ce334 100644
> --- a/security/selinux/include/objsec.h
> +++ b/security/selinux/include/objsec.h
> @@ -150,6 +150,10 @@ struct pkey_security_struct {
> u32 sid; /* SID of pkey */
> };
>
> +struct bpf_security_struct {
> + u32 sid; /*SID of bpf obj creater*/
> +};
> +
> extern unsigned int selinux_checkreqprot;
>
> #endif /* _SELINUX_OBJSEC_H_ */
^ permalink raw reply
* Re: [PATCH net-next 4/4] selinux: bpf: Add addtional check for bpf object file receive
From: Stephen Smalley @ 2017-10-05 13:37 UTC (permalink / raw)
To: Chenbo Feng, netdev, SELinux, linux-security-module
Cc: Chenbo Feng, Alexei Starovoitov, Daniel Borkmann, Lorenzo Colitti
In-Reply-To: <20171004182932.140028-5-chenbofeng.kernel@gmail.com>
On Wed, 2017-10-04 at 11:29 -0700, Chenbo Feng wrote:
> From: Chenbo Feng <fengc@google.com>
>
> Introduce a bpf object related check when sending and receiving files
> through unix domain socket as well as binder. It checks if the
> receiving
> process have privilege to read/write the bpf map or use the bpf
> program.
> This check is necessary because the bpf maps and programs are using a
> anonymous inode as their shared inode so the normal way of checking
> the
> files and sockets when passing between processes cannot work properly
> on
> eBPF object. This check only works when the BPF_SYSCALL is
> configured.
>
> Signed-off-by: Chenbo Feng <fengc@google.com>
> ---
> include/linux/bpf.h | 3 +++
> kernel/bpf/syscall.c | 4 ++--
> security/selinux/hooks.c | 57
> +++++++++++++++++++++++++++++++++++++++++++++++-
> 3 files changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index d757ea3f2228..ac8428a36d56 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -250,6 +250,9 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog,
> const union bpf_attr *kattr,
> #ifdef CONFIG_BPF_SYSCALL
> DECLARE_PER_CPU(int, bpf_prog_active);
>
> +extern const struct file_operations bpf_map_fops;
> +extern const struct file_operations bpf_prog_fops;
> +
> #define BPF_PROG_TYPE(_id, _ops) \
> extern const struct bpf_verifier_ops _ops;
> #define BPF_MAP_TYPE(_id, _ops) \
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 58ff769d58ab..5789a5359f0a 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -313,7 +313,7 @@ static ssize_t bpf_dummy_write(struct file *filp,
> const char __user *buf,
> return -EINVAL;
> }
>
> -static const struct file_operations bpf_map_fops = {
> +const struct file_operations bpf_map_fops = {
> #ifdef CONFIG_PROC_FS
> .show_fdinfo = bpf_map_show_fdinfo,
> #endif
> @@ -965,7 +965,7 @@ static void bpf_prog_show_fdinfo(struct seq_file
> *m, struct file *filp)
> }
> #endif
>
> -static const struct file_operations bpf_prog_fops = {
> +const struct file_operations bpf_prog_fops = {
> #ifdef CONFIG_PROC_FS
> .show_fdinfo = bpf_prog_show_fdinfo,
> #endif
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 41aba4e3d57c..381474ce3216 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1847,6 +1847,7 @@ static int file_has_perm(const struct cred
> *cred,
>
> /* av is zero if only checking access to the descriptor. */
> rc = 0;
> +
> if (av)
> rc = inode_has_perm(cred, inode, av, &ad);
>
> @@ -2142,6 +2143,10 @@ static int
> selinux_binder_transfer_binder(struct task_struct *from,
> NULL);
> }
>
> +#ifdef CONFIG_BPF_SYSCALL
> +static int bpf_fd_pass(struct file *file, u32 sid);
> +#endif
> +
> static int selinux_binder_transfer_file(struct task_struct *from,
> struct task_struct *to,
> struct file *file)
> @@ -2165,6 +2170,12 @@ static int selinux_binder_transfer_file(struct
> task_struct *from,
> return rc;
> }
>
> +#ifdef CONFIG_BPF_SYSCALL
> + rc = bpf_fd_pass(file, sid);
> + if (rc)
> + return rc;
> +#endif
> +
> if (unlikely(IS_PRIVATE(d_backing_inode(dentry))))
> return 0;
>
> @@ -3735,8 +3746,18 @@ static int selinux_file_send_sigiotask(struct
> task_struct *tsk,
> static int selinux_file_receive(struct file *file)
> {
> const struct cred *cred = current_cred();
> + int rc;
> +
> + rc = file_has_perm(cred, file, file_to_av(file));
> + if (rc)
> + goto out;
> +
> +#ifdef CONFIG_BPF_SYSCALL
> + rc = bpf_fd_pass(file, cred_sid(sid));
> +#endif
>
> - return file_has_perm(cred, file, file_to_av(file));
> +out:
> + return rc;
> }
>
> static int selinux_file_open(struct file *file, const struct cred
> *cred)
> @@ -6288,6 +6309,40 @@ static u32 bpf_map_fmode_to_av(fmode_t fmode)
> return av;
> }
>
> +/* This function will check the file pass through unix socket or
> binder to see
> + * if it is a bpf related object. And apply correspinding checks on
> the bpf
> + * object based on the type. The bpf maps and programs, not like
> other files and
> + * socket, are using a shared anonymous inode inside the kernel as
> their inode.
> + * So checking that inode cannot identify if the process have
> privilege to
> + * access the bpf object and that's why we have to add this
> additional check in
> + * selinux_file_receive and selinux_binder_transfer_files.
> + */
> +static int bpf_fd_pass(struct file *file, u32 sid)
> +{
> + struct bpf_security_struct *bpfsec;
> + u32 sid = cred_sid(cred);
> + struct bpf_prog *prog;
> + struct bpf_map *map;
> + int ret;
> +
> + if (file->f_op == &bpf_map_fops) {
> + map = file->private_data;
> + bpfsec = map->security;
> + ret = avc_has_perm(sid, bpfsec->sid,
> SECCLASS_BPF_MAP,
> + bpf_map_fmode_to_av(file-
> >f_mode), NULL);
> + if (ret)
> + return ret;
> + } else if (file->f_op == &bpf_prog_fops) {
> + prog = file->private_data;
> + bpfsec = prog->aux->security;
> + ret = avc_has_perm(sid, bpfsec->sid,
> SECCLASS_BPF_PROG,
> + BPF_PROG__USE, NULL);
> + if (ret)
> + return ret;
> + }
> + return 0;
> +}
When the struct file is allocated for the bpf map and/or prog, you
could call a hook at that time passing both, and note the fact that it
is a bpf map/prog in the file_security_struct. Then, on
file_receive/binder_transfer_file, you could apply the appropriate
checking. Further, if we know that the file is always allocated at the
same point as the bpf map/prog, then they should have the same SID (i.e
fsec->sid should be the same as bpfsec->sid), so we shouldn't even need
to dereference the bpf map/prog. Unless I'm missing something.
Also, are we concerned about doing the same in
flush_unauthorized_files(), for inheriting descriptors across a
context-changing execve? Should this checking actually go into
file_has_perm() itself so it is always applied on any use of the struct
file?
Lastly, do we need/want these checks if sid == bpfsec->sid? We skip
FD__USE in the case where sid == fsec->sid, for example.
> +
> static int selinux_bpf_map(struct bpf_map *map, fmode_t fmode)
> {
> u32 sid = current_sid();
^ permalink raw reply
* Re: [PATCH 3/3] ARM: dts: gr-peach: Add ETHER pin group
From: Andrew Lunn @ 2017-10-05 13:43 UTC (permalink / raw)
To: jacopo mondi; +Cc: Geert Uytterhoeven, Chris Brandt, f.fainelli, netdev
In-Reply-To: <20171005093915.GP4037@w540>
On Thu, Oct 05, 2017 at 11:39:15AM +0200, jacopo mondi wrote:
> Hi Geert
>
> On Thu, Oct 05, 2017 at 11:09:40AM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
> > On Thu, Oct 5, 2017 at 10:58 AM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> > > Add pin configuration subnode for ETHER pin group and enable the interface.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > > --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > > +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> >
> > > @@ -88,3 +110,19 @@
> > >
> > > status = "okay";
> > > };
> > > +
> > > +ðer {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <ðer_pins>;
> > > +
> > > + status = "okay";
> > > +
> > > + reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > > + reset-delay-us = <5>;
> >
> > I'm afraid the PHY people (not CCed ;-) will want you to move these reset
> > properties to the phy subnode these days, despite
> > Documentation/devicetree/bindings/net/mdio.txt...
Hi Jocopo
So what is this reset resetting?
The MAC?
The PHY?
Andrew
^ permalink raw reply
* Re: [PATCH] netfilter: ipset: Convert timers to use timer_setup()
From: Jozsef Kadlecsik @ 2017-10-05 13:58 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, Pablo Neira Ayuso, Florian Westphal,
David S. Miller, Stephen Hemminger, simran singhal,
Muhammad Falak R Wani, netfilter-devel, coreteam, netdev,
Thomas Gleixner
In-Reply-To: <20171005005221.GA23584@beast>
Hi,
On Wed, 4 Oct 2017, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer
> to all timer callbacks, switch to using the new timer_setup() and
> from_timer() to pass the timer pointer explicitly. This introduces a
> pointer back to the struct ip_set, which is used instead of the struct
> timer_list .data field.
Please add the same changes to net/netfilter/ipset/ip_set_list.c too, in
order to handle all ipset modules in a single patch. I don't see a way
either to avoid the introduction of the new pointer.
Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Best regards,
Jozsef
> Cc: Pablo Neira Ayuso <pablo@netfilter.org>
> Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
> Cc: Florian Westphal <fw@strlen.de>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: simran singhal <singhalsimran0@gmail.com>
> Cc: Muhammad Falak R Wani <falakreyaz@gmail.com>
> Cc: netfilter-devel@vger.kernel.org
> Cc: coreteam@netfilter.org
> Cc: netdev@vger.kernel.org
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.
> ---
> net/netfilter/ipset/ip_set_bitmap_gen.h | 10 +++++-----
> net/netfilter/ipset/ip_set_bitmap_ip.c | 2 ++
> net/netfilter/ipset/ip_set_bitmap_ipmac.c | 2 ++
> net/netfilter/ipset/ip_set_bitmap_port.c | 2 ++
> net/netfilter/ipset/ip_set_hash_gen.h | 12 +++++++-----
> 5 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/net/netfilter/ipset/ip_set_bitmap_gen.h b/net/netfilter/ipset/ip_set_bitmap_gen.h
> index 8ad2b52a0b32..5ca18f07683b 100644
> --- a/net/netfilter/ipset/ip_set_bitmap_gen.h
> +++ b/net/netfilter/ipset/ip_set_bitmap_gen.h
> @@ -37,11 +37,11 @@
> #define get_ext(set, map, id) ((map)->extensions + ((set)->dsize * (id)))
>
> static void
> -mtype_gc_init(struct ip_set *set, void (*gc)(unsigned long ul_set))
> +mtype_gc_init(struct ip_set *set, void (*gc)(struct timer_list *t))
> {
> struct mtype *map = set->data;
>
> - setup_timer(&map->gc, gc, (unsigned long)set);
> + timer_setup(&map->gc, gc, 0);
> mod_timer(&map->gc, jiffies + IPSET_GC_PERIOD(set->timeout) * HZ);
> }
>
> @@ -272,10 +272,10 @@ mtype_list(const struct ip_set *set,
> }
>
> static void
> -mtype_gc(unsigned long ul_set)
> +mtype_gc(struct timer_list *t)
> {
> - struct ip_set *set = (struct ip_set *)ul_set;
> - struct mtype *map = set->data;
> + struct mtype *map = from_timer(map, t, gc);
> + struct ip_set *set = map->set;
> void *x;
> u32 id;
>
> diff --git a/net/netfilter/ipset/ip_set_bitmap_ip.c b/net/netfilter/ipset/ip_set_bitmap_ip.c
> index 4783efff0bde..d8975a0b4282 100644
> --- a/net/netfilter/ipset/ip_set_bitmap_ip.c
> +++ b/net/netfilter/ipset/ip_set_bitmap_ip.c
> @@ -48,6 +48,7 @@ struct bitmap_ip {
> size_t memsize; /* members size */
> u8 netmask; /* subnet netmask */
> struct timer_list gc; /* garbage collection */
> + struct ip_set *set; /* attached to this ip_set */
> unsigned char extensions[0] /* data extensions */
> __aligned(__alignof__(u64));
> };
> @@ -232,6 +233,7 @@ init_map_ip(struct ip_set *set, struct bitmap_ip *map,
> map->netmask = netmask;
> set->timeout = IPSET_NO_TIMEOUT;
>
> + map->set = set;
> set->data = map;
> set->family = NFPROTO_IPV4;
>
> diff --git a/net/netfilter/ipset/ip_set_bitmap_ipmac.c b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
> index 9a065f672d3a..4c279fbd2d5d 100644
> --- a/net/netfilter/ipset/ip_set_bitmap_ipmac.c
> +++ b/net/netfilter/ipset/ip_set_bitmap_ipmac.c
> @@ -52,6 +52,7 @@ struct bitmap_ipmac {
> u32 elements; /* number of max elements in the set */
> size_t memsize; /* members size */
> struct timer_list gc; /* garbage collector */
> + struct ip_set *set; /* attached to this ip_set */
> unsigned char extensions[0] /* MAC + data extensions */
> __aligned(__alignof__(u64));
> };
> @@ -307,6 +308,7 @@ init_map_ipmac(struct ip_set *set, struct bitmap_ipmac *map,
> map->elements = elements;
> set->timeout = IPSET_NO_TIMEOUT;
>
> + map->set = set;
> set->data = map;
> set->family = NFPROTO_IPV4;
>
> diff --git a/net/netfilter/ipset/ip_set_bitmap_port.c b/net/netfilter/ipset/ip_set_bitmap_port.c
> index 7f0c733358a4..7f9bbd7c98b5 100644
> --- a/net/netfilter/ipset/ip_set_bitmap_port.c
> +++ b/net/netfilter/ipset/ip_set_bitmap_port.c
> @@ -40,6 +40,7 @@ struct bitmap_port {
> u32 elements; /* number of max elements in the set */
> size_t memsize; /* members size */
> struct timer_list gc; /* garbage collection */
> + struct ip_set *set; /* attached to this ip_set */
> unsigned char extensions[0] /* data extensions */
> __aligned(__alignof__(u64));
> };
> @@ -214,6 +215,7 @@ init_map_port(struct ip_set *set, struct bitmap_port *map,
> map->last_port = last_port;
> set->timeout = IPSET_NO_TIMEOUT;
>
> + map->set = set;
> set->data = map;
> set->family = NFPROTO_UNSPEC;
>
> diff --git a/net/netfilter/ipset/ip_set_hash_gen.h b/net/netfilter/ipset/ip_set_hash_gen.h
> index 51063d9ed0f7..efffc8eabafe 100644
> --- a/net/netfilter/ipset/ip_set_hash_gen.h
> +++ b/net/netfilter/ipset/ip_set_hash_gen.h
> @@ -280,6 +280,7 @@ htable_bits(u32 hashsize)
> struct htype {
> struct htable __rcu *table; /* the hash table */
> struct timer_list gc; /* garbage collection when timeout enabled */
> + struct ip_set *set; /* attached to this ip_set */
> u32 maxelem; /* max elements in the hash */
> u32 initval; /* random jhash init value */
> #ifdef IP_SET_HASH_WITH_MARKMASK
> @@ -429,11 +430,11 @@ mtype_destroy(struct ip_set *set)
> }
>
> static void
> -mtype_gc_init(struct ip_set *set, void (*gc)(unsigned long ul_set))
> +mtype_gc_init(struct ip_set *set, void (*gc)(struct timer_list *t))
> {
> struct htype *h = set->data;
>
> - setup_timer(&h->gc, gc, (unsigned long)set);
> + timer_setup(&h->gc, gc, 0);
> mod_timer(&h->gc, jiffies + IPSET_GC_PERIOD(set->timeout) * HZ);
> pr_debug("gc initialized, run in every %u\n",
> IPSET_GC_PERIOD(set->timeout));
> @@ -526,10 +527,10 @@ mtype_expire(struct ip_set *set, struct htype *h)
> }
>
> static void
> -mtype_gc(unsigned long ul_set)
> +mtype_gc(struct timer_list *t)
> {
> - struct ip_set *set = (struct ip_set *)ul_set;
> - struct htype *h = set->data;
> + struct htype *h = from_timer(h, t, gc);
> + struct ip_set *set = h->set;
>
> pr_debug("called\n");
> spin_lock_bh(&set->lock);
> @@ -1314,6 +1315,7 @@ IPSET_TOKEN(HTYPE, _create)(struct net *net, struct ip_set *set,
> t->htable_bits = hbits;
> RCU_INIT_POINTER(h->table, t);
>
> + h->set = set;
> set->data = h;
> #ifndef IP_SET_PROTO_UNDEF
> if (set->family == NFPROTO_IPV4) {
> --
> 2.7.4
>
>
> --
> Kees Cook
> Pixel Security
>
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* RE: [PATCH net-next] ip_gre: check packet length and mtu correctly in erspan_fb_xmit
From: David Laight @ 2017-10-05 13:59 UTC (permalink / raw)
To: 'William Tu', netdev@vger.kernel.org; +Cc: Xin Long
In-Reply-To: <1507162445-18540-1-git-send-email-u9012063@gmail.com>
From: William Tu
> Sent: 05 October 2017 01:14
> Similarly to early patch for erspan_xmit(), the ARPHDR_ETHER device
> is the length of the whole ether packet. So skb->len should subtract
> the dev->hard_header_len.
>
> Fixes: 1a66a836da63 ("gre: add collect_md mode to ERSPAN tunnel")
> Signed-off-by: William Tu <u9012063@gmail.com>
> Cc: Xin Long <lucien.xin@gmail.com>
> ---
> net/ipv4/ip_gre.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index b279c325c7f6..10b21fe5b3a6 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -579,7 +579,7 @@ static void erspan_fb_xmit(struct sk_buff *skb, struct net_device *dev,
> if (gre_handle_offloads(skb, false))
> goto err_free_rt;
>
> - if (skb->len > dev->mtu) {
> + if (skb->len - dev->hard_header_len > dev->mtu) {
Can you guarantee that skb->len > dev_hard_header_len?
It is probably safer to check skb->len > dev->hard_header_len + dev->mtu
since that addition isn't going to overflow.
> pskb_trim(skb, dev->mtu);
> truncate = true;
Is that pskb_trim() now truncating to the correct size?
David
^ permalink raw reply
* (unknown),
From: informationrequest @ 2017-10-05 14:24 UTC (permalink / raw)
To: netdev
[-- Attachment #1: SALE-877553024907700netdev.zip --]
[-- Type: application/zip, Size: 7221 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v4 1/3] bridge: add new BR_NEIGH_SUPPRESS port flag to suppress arp and nd flood
From: Roopa Prabhu @ 2017-10-05 14:31 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Nikolay Aleksandrov,
stephen@networkplumber.org, bridge
In-Reply-To: <20171004.155255.2208423870631197976.davem@davemloft.net>
On Wed, Oct 4, 2017 at 3:52 PM, David Miller <davem@davemloft.net> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
> Date: Tue, 3 Oct 2017 22:12:31 -0700
>
>> BR_ARP_PROXY flag but has a few semantic differences to conform
>
> This should be "BR_PROXYARP".
ack, will fix.
>
> Otherwise this series looks fine to me, but I see there will be
> a v5 respin.
yes, working on v5. I am currently testing a few more cases for
locally generated arp/nd packets with bridge as the src dev (related
to some questions from Toshiaki).
Thanks!.
^ permalink raw reply
* [PATCH net-next v3 0/2] libbpf: support more map options
From: Craig Gallek @ 2017-10-05 14:41 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
David S . Miller
Cc: Chonggang Li, netdev
From: Craig Gallek <kraig@google.com>
The functional change to this series is the ability to use flags when
creating maps from object files loaded by libbpf. In order to do this,
the first patch updates the library to handle map definitions that
differ in size from libbpf's struct bpf_map_def.
For object files with a larger map definition, libbpf will continue to load
if the unknown fields are all zero, otherwise the map is rejected. If the
map definition in the object file is smaller than expected, libbpf will use
zero as a default value in the missing fields.
Craig Gallek (2):
libbpf: parse maps sections of varying size
libbpf: use map_flags when creating maps
tools/lib/bpf/libbpf.c | 72 +++++++++++++++++++++++++++++---------------------
tools/lib/bpf/libbpf.h | 1 +
2 files changed, 43 insertions(+), 30 deletions(-)
--
v3:
- explicit memcpy instead of struct assignment.
- remove unnecessary bpf_object__validate_maps function
v2
- determine bpf_map_def structure size dynamically from object file
2.14.2.920.gcf0c67979c-goog
^ permalink raw reply
* [PATCH net-next v3 1/2] libbpf: parse maps sections of varying size
From: Craig Gallek @ 2017-10-05 14:41 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
David S . Miller
Cc: Chonggang Li, netdev
In-Reply-To: <20171005144158.14860-1-kraigatgoog@gmail.com>
From: Craig Gallek <kraig@google.com>
This library previously assumed a fixed-size map options structure.
Any new options were ignored. In order to allow the options structure
to grow and to support parsing older programs, this patch updates
the maps section parsing to handle varying sizes.
Object files with maps sections smaller than expected will have the new
fields initialized to zero. Object files which have larger than expected
maps sections will be rejected unless all of the unrecognized data is zero.
This change still assumes that each map definition in the maps section
is the same size.
Signed-off-by: Craig Gallek <kraig@google.com>
---
tools/lib/bpf/libbpf.c | 70 +++++++++++++++++++++++++++++---------------------
1 file changed, 41 insertions(+), 29 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 4f402dcdf372..23152890ec60 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -579,31 +579,6 @@ bpf_object__init_kversion(struct bpf_object *obj,
return 0;
}
-static int
-bpf_object__validate_maps(struct bpf_object *obj)
-{
- int i;
-
- /*
- * If there's only 1 map, the only error case should have been
- * catched in bpf_object__init_maps().
- */
- if (!obj->maps || !obj->nr_maps || (obj->nr_maps == 1))
- return 0;
-
- for (i = 1; i < obj->nr_maps; i++) {
- const struct bpf_map *a = &obj->maps[i - 1];
- const struct bpf_map *b = &obj->maps[i];
-
- if (b->offset - a->offset < sizeof(struct bpf_map_def)) {
- pr_warning("corrupted map section in %s: map \"%s\" too small\n",
- obj->path, a->name);
- return -EINVAL;
- }
- }
- return 0;
-}
-
static int compare_bpf_map(const void *_a, const void *_b)
{
const struct bpf_map *a = _a;
@@ -615,7 +590,7 @@ static int compare_bpf_map(const void *_a, const void *_b)
static int
bpf_object__init_maps(struct bpf_object *obj)
{
- int i, map_idx, nr_maps = 0;
+ int i, map_idx, map_def_sz, nr_maps = 0;
Elf_Scn *scn;
Elf_Data *data;
Elf_Data *symbols = obj->efile.symbols;
@@ -658,6 +633,15 @@ bpf_object__init_maps(struct bpf_object *obj)
if (!nr_maps)
return 0;
+ /* Assume equally sized map definitions */
+ map_def_sz = data->d_size / nr_maps;
+ if (!data->d_size || (data->d_size % nr_maps) != 0) {
+ pr_warning("unable to determine map definition size "
+ "section %s, %d maps in %zd bytes\n",
+ obj->path, nr_maps, data->d_size);
+ return -EINVAL;
+ }
+
obj->maps = calloc(nr_maps, sizeof(obj->maps[0]));
if (!obj->maps) {
pr_warning("alloc maps for object failed\n");
@@ -690,7 +674,7 @@ bpf_object__init_maps(struct bpf_object *obj)
obj->efile.strtabidx,
sym.st_name);
obj->maps[map_idx].offset = sym.st_value;
- if (sym.st_value + sizeof(struct bpf_map_def) > data->d_size) {
+ if (sym.st_value + map_def_sz > data->d_size) {
pr_warning("corrupted maps section in %s: last map \"%s\" too small\n",
obj->path, map_name);
return -EINVAL;
@@ -704,12 +688,40 @@ bpf_object__init_maps(struct bpf_object *obj)
pr_debug("map %d is \"%s\"\n", map_idx,
obj->maps[map_idx].name);
def = (struct bpf_map_def *)(data->d_buf + sym.st_value);
- obj->maps[map_idx].def = *def;
+ /*
+ * If the definition of the map in the object file fits in
+ * bpf_map_def, copy it. Any extra fields in our version
+ * of bpf_map_def will default to zero as a result of the
+ * calloc above.
+ */
+ if (map_def_sz <= sizeof(struct bpf_map_def)) {
+ memcpy(&obj->maps[map_idx].def, def, map_def_sz);
+ } else {
+ /*
+ * Here the map structure being read is bigger than what
+ * we expect, truncate if the excess bits are all zero.
+ * If they are not zero, reject this map as
+ * incompatible.
+ */
+ char *b;
+ for (b = ((char *)def) + sizeof(struct bpf_map_def);
+ b < ((char *)def) + map_def_sz; b++) {
+ if (*b != 0) {
+ pr_warning("maps section in %s: \"%s\" "
+ "has unrecognized, non-zero "
+ "options\n",
+ obj->path, map_name);
+ return -EINVAL;
+ }
+ }
+ memcpy(&obj->maps[map_idx].def, def,
+ sizeof(struct bpf_map_def));
+ }
map_idx++;
}
qsort(obj->maps, obj->nr_maps, sizeof(obj->maps[0]), compare_bpf_map);
- return bpf_object__validate_maps(obj);
+ return 0;
}
static int bpf_object__elf_collect(struct bpf_object *obj)
--
2.14.2.920.gcf0c67979c-goog
^ permalink raw reply related
* [PATCH net-next v3 2/2] libbpf: use map_flags when creating maps
From: Craig Gallek @ 2017-10-05 14:41 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
David S . Miller
Cc: Chonggang Li, netdev
In-Reply-To: <20171005144158.14860-1-kraigatgoog@gmail.com>
From: Craig Gallek <kraig@google.com>
This is required to use BPF_MAP_TYPE_LPM_TRIE or any other map type
which requires flags.
Signed-off-by: Craig Gallek <kraig@google.com>
---
tools/lib/bpf/libbpf.c | 2 +-
tools/lib/bpf/libbpf.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 23152890ec60..5aa45f89da93 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -942,7 +942,7 @@ bpf_object__create_maps(struct bpf_object *obj)
def->key_size,
def->value_size,
def->max_entries,
- 0);
+ def->map_flags);
if (*pfd < 0) {
size_t j;
int err = *pfd;
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index 7959086eb9c9..6e20003109e0 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -207,6 +207,7 @@ struct bpf_map_def {
unsigned int key_size;
unsigned int value_size;
unsigned int max_entries;
+ unsigned int map_flags;
};
/*
--
2.14.2.920.gcf0c67979c-goog
^ permalink raw reply related
* RE: [PATCH net-next 01/10] net/smc: add missing dev_put
From: Parav Pandit @ 2017-10-05 14:44 UTC (permalink / raw)
To: Ursula Braun
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org,
jwi@linux.vnet.ibm.com, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, raspl@linux.vnet.ibm.com
In-Reply-To: <7961df23-1603-7853-5f3e-f31095aebba0@linux.vnet.ibm.com>
Hi Ursula,
> -----Original Message-----
> From: Ursula Braun [mailto:ubraun@linux.vnet.ibm.com]
> Sent: Thursday, October 05, 2017 2:54 AM
> To: Parav Pandit <parav@mellanox.com>
> Cc: davem@davemloft.net; netdev@vger.kernel.org; linux-
> rdma@vger.kernel.org; linux-s390@vger.kernel.org; jwi@linux.vnet.ibm.com;
> schwidefsky@de.ibm.com; heiko.carstens@de.ibm.com;
> raspl@linux.vnet.ibm.com
> Subject: Re: [PATCH net-next 01/10] net/smc: add missing dev_put
>
>
>
> On 10/02/2017 10:36 PM, Parav Pandit wrote:
> > Hi Ursula, Dave, Hans,
> >
> >> -----Original Message-----
> >> From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma-
> >> owner@vger.kernel.org] On Behalf Of Ursula Braun
> >> Sent: Wednesday, September 20, 2017 6:58 AM
> >> To: davem@davemloft.net
> >> Cc: netdev@vger.kernel.org; linux-rdma@vger.kernel.org; linux-
> >> s390@vger.kernel.org; jwi@linux.vnet.ibm.com; schwidefsky@de.ibm.com;
> >> heiko.carstens@de.ibm.com; raspl@linux.vnet.ibm.com;
> >> ubraun@linux.vnet.ibm.com
> >> Subject: [PATCH net-next 01/10] net/smc: add missing dev_put
> >>
> >> From: Hans Wippel <hwippel@linux.vnet.ibm.com>
> >>
> >> In the infiniband part, SMC currently uses get_netdev which calls
> >> dev_hold on the returned net device. However, the SMC code never
> >> calls dev_put on that net device resulting in a wrong reference count.
> >>
> >> This patch adds a dev_put after the usage of the net device to fix the issue.
> >>
> >> Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
> >> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
> >> ---
> >> net/smc/smc_ib.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/net/smc/smc_ib.c b/net/smc/smc_ib.c index
> >> 547e0e113b17..0b5852299158 100644
> >> --- a/net/smc/smc_ib.c
> >> +++ b/net/smc/smc_ib.c
> >> @@ -380,6 +380,7 @@ static int smc_ib_fill_gid_and_mac(struct
> >> smc_ib_device *smcibdev, u8 ibport)
> >> ndev = smcibdev->ibdev->get_netdev(smcibdev->ibdev, ibport);
> >> if (ndev) {
> >> memcpy(&smcibdev->mac, ndev->dev_addr, ETH_ALEN);
> >> + dev_put(ndev);
> >
> > I am sorry for providing late comments. smc_ib_fill_gid_and_mac() is not
> coded correctly.
> > Few fixes are needed.
> > 1. ULP such as SMC should not open code/deference any function pointer like
> get_netdev() of the IB device.
> > 2. Replace ib_query_gid(..., NULL)
> > With
> > ib_query_gid(..., gid_attr);
> >
> > Use gid_attr.ndev to get the MAC address.
> > Do dev_put(gid_attr.ndev);
> >
> > Code should look like below,
> >
> > struct ib_gid_attr gid_attr;
> >
> > rc = ib_query_gid(..., &gid_attr);
> > if (rc || !gid_addr.ndev)
> > return -ENODEV;
> > else
> > memcpy(smcibdev->mac, ndev->dev_addr, ETH_ALEN);
> > dev_put(gid_addr.ndev);
> >
>
> Thanks, Parav!
> Following your fix ideas I plan to change the function into this one:
>
> static int smc_ib_fill_gid_and_mac(struct smc_ib_device *smcibdev, u8 ibport) {
> struct ib_gid_attr gattr;
> int rc;
>
> rc = ib_query_gid(smcibdev->ibdev, ibport, 0,
> &smcibdev->gid[ibport - 1], &gattr);
> /* the SMC protocol requires specification of the roce MAC address;
> * if net_device cannot be determined, it can be derived from gid 0
> */
> if (rc)
> return rc;
>
> if (gattr.ndev) {
> memcpy(&smcibdev->mac, gattr.ndev->dev_addr, ETH_ALEN);
> dev_put(gattr.ndev);
> } else {
> memcpy(&smcibdev->mac[ibport - 1][0],
> &smcibdev->gid[ibport - 1].raw[8], 3);
> memcpy(&smcibdev->mac[ibport - 1][3],
> &smcibdev->gid[ibport - 1].raw[13], 3);
> smcibdev->mac[ibport - 1][0] &= ~0x02;
This else part is not needed. You can fail the call as suggested above, inline below too.
if (rc || !gid_addr.ndev)
return -ENODEV;
There must be valid netdev for RoCE gid.
Rest code looks fine.
^ permalink raw reply
* Re: BUG in free_netdev() on ppp link deletion
From: Guillaume Nault @ 2017-10-05 14:55 UTC (permalink / raw)
To: Beniamino Galvani
Cc: linux-ppp, netdev, Paul Mackerras, David Ahern, Gao Feng
In-Reply-To: <20171003164003.f5yay2oe6dhxnump@alphalink.fr>
On Tue, Oct 03, 2017 at 06:40:03PM +0200, Guillaume Nault wrote:
> On Tue, Oct 03, 2017 at 09:44:14AM +0200, Beniamino Galvani wrote:
> > Call Trace:
> > ppp_destroy_interface+0xd8/0xe0 [ppp_generic]
> > ppp_disconnect_channel+0xda/0x110 [ppp_generic]
> > ppp_unregister_channel+0x5e/0x110 [ppp_generic]
> > pppox_unbind_sock+0x23/0x30 [pppox]
> > pppoe_connect+0x130/0x440 [pppoe]
> > SYSC_connect+0x98/0x110
> > ? do_fcntl+0x2c0/0x5d0
> > SyS_connect+0xe/0x10
> > entry_SYSCALL_64_fastpath+0x1a/0xa5
> > RIP: 0033:0x7fa71f4af840
> > RSP: 002b:00007ffe4ea40bf8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
> > RAX: ffffffffffffffda RBX: 0000556d37ae0538 RCX: 00007fa71f4af840
> > RDX: 000000000000001e RSI: 00007ffe4ea40c00 RDI: 0000000000000008
> > RBP: 0000556d37b2a1b0 R08: 0000556d396e95b0 R09: 0000000000000008
> > R10: 00000000aaaaaaab R11: 0000000000000246 R12: 0000556d37adc008
> > R13: 0000556d37adc004 R14: 0000556d37b2a1a4 R15: 0000000000000000
> > Code: 04 00 00 04 e8 cb 52 e3 ff 5b 41 5c 41 5d 5d c3 41 0f b7 84 24 32 02 00 00 4c 89 e7 48 29 c7 e8 80 8b aa ff 5b 41 5c 41 5d 5d c3 <0f> 0b 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 41
> > RIP: free_netdev+0x107/0x110 RSP: ffffc28a40573d88
> > ---[ end trace ed294ff0cc40eeff ]---
> >
> > To reproduce this, establish a PPP connection through pppd, then bring
> > down and delete the ppp interface:
> >
> > # pppd nodetach lock user client plugin rp-pppoe.so ens11 noauth nodeflate password password &
> > Plugin rp-pppoe.so loaded.
> > RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
> > PPP session is 16
> > Connected to fe:54:00:5f:04:13 via interface ens11
> > Using interface ppp0
> > Connect: ppp0 <--> ens11
> > CHAP authentication succeeded: Access granted
> > CHAP authentication succeeded
> > peer from calling number FE:54:00:5F:04:13 authorized
> > local IP address 3.1.1.10
> > remote IP address 3.1.1.1
> >
> > # ip l set ppp0 down
> > # ip l del ppp0
> >
> > It does not happen every time but only when ppp_destroy_interface() is
> > called with dev->reg_state = UNREGISTERING, set by the concurrent
> > rtnl_delete_link().
> >
> Indeed, we have a race here: ppp_destroy_interface() can be called before
> netdev_run_todo() completes. I'm working on it.
>
Sorry for the delay, I've followed a few complicated dead ends before
getting to this simple and rather obvious fix.
Can you try this patch?
-------- 8< --------
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index c3f77e3b7819..e365866600ba 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -1339,7 +1339,17 @@ ppp_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats64)
static int ppp_dev_init(struct net_device *dev)
{
+ struct ppp *ppp;
+
netdev_lockdep_set_classes(dev);
+
+ ppp = netdev_priv(dev);
+ /* Let the netdevice take a reference on the ppp file. This ensures
+ * that ppp_destroy_interface() won't run before the device gets
+ * unregistered.
+ */
+ atomic_inc(&ppp->file.refcnt);
+
return 0;
}
@@ -1362,6 +1372,15 @@ static void ppp_dev_uninit(struct net_device *dev)
wake_up_interruptible(&ppp->file.rwait);
}
+static void ppp_dev_priv_destructor(struct net_device *dev)
+{
+ struct ppp *ppp;
+
+ ppp = netdev_priv(dev);
+ if (atomic_dec_and_test(&ppp->file.refcnt))
+ ppp_destroy_interface(ppp);
+}
+
static const struct net_device_ops ppp_netdev_ops = {
.ndo_init = ppp_dev_init,
.ndo_uninit = ppp_dev_uninit,
@@ -1387,6 +1406,7 @@ static void ppp_setup(struct net_device *dev)
dev->tx_queue_len = 3;
dev->type = ARPHRD_PPP;
dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
+ dev->priv_destructor = ppp_dev_priv_destructor;
netif_keep_dst(dev);
}
^ permalink raw reply related
* RE: [PATCH] rsi: fix integer overflow warning
From: David Laight @ 2017-10-05 15:12 UTC (permalink / raw)
To: 'Joe Perches', Arnd Bergmann, Kalle Valo,
Prameela Rani Garnepudi, Amitkumar Karwar
Cc: Pavani Muthyala, Karun Eagalapati, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1507205947.4434.23.camel@perches.com>
From: Joe Perches
> Sent: 05 October 2017 13:19
> On Thu, 2017-10-05 at 14:05 +0200, Arnd Bergmann wrote:
> > gcc produces a harmless warning about a recently introduced
> > signed integer overflow:
> >
> > drivers/net/wireless/rsi/rsi_91x_hal.c: In function 'rsi_prepare_mgmt_desc':
> > include/uapi/linux/swab.h:13:15: error: integer overflow in expression [-Werror=overflow]
> > (((__u16)(x) & (__u16)0x00ffU) << 8) | \
> > ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
> > include/uapi/linux/swab.h:104:2: note: in expansion of macro '___constant_swab16'
> > ___constant_swab16(x) : \
> > ^~~~~~~~~~~~~~~~~~
> > include/uapi/linux/byteorder/big_endian.h:34:43: note: in expansion of macro '__swab16'
> > #define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
>
> []
>
> > The problem is that the 'mask' value is a signed integer that gets
> > turned into a negative number when truncated to 16 bits. Making it
> > an unsigned constant avoids this.
>
> I would expect there are more of these.
>
> Perhaps this define in include/uapi/linux/swab.h:
>
> #define __swab16(x) \
> (__builtin_constant_p((__u16)(x)) ? \
> ___constant_swab16(x) : \
> __fswab16(x))
>
> should be
>
> #define __swab16(x) \
> (__builtin_constant_p((__u16)(x)) ? \
> ___constant_swab16((__u16)(x)) : \
> __fswab16((__u16)(x)))
You probably don't want the cast in the call to __fswab16() since
that is likely to generate an explicit and with 0xffff.
You will likely also get one if the argument is _u16 (not unsigned int).
David
^ permalink raw reply
* Re: [PATCH] mwifiex: Use put_unaligned_le32
From: Himanshu Jha @ 2017-10-05 15:22 UTC (permalink / raw)
To: Kalle Valo
Cc: amitkarwar, nishants, gbhat, huxm, linux-wireless, netdev,
linux-kernel
In-Reply-To: <87zi963s1p.fsf@codeaurora.org>
On Thu, Oct 05, 2017 at 11:41:38AM +0300, Kalle Valo wrote:
> Himanshu Jha <himanshujha199640@gmail.com> writes:
>
> >> > --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> >> > +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> >> > @@ -17,6 +17,7 @@
> >> > * this warranty disclaimer.
> >> > */
> >> >
> >> > +#include <linux/unaligned/access_ok.h>
> >>
> >> I don't think this is correct. Should it be asm/unaligned.h?
> >
> > Would mind explainig me as to why it is incorrect! Also, it defined in
> > both the header files but, why is asm/unaligned.h preferred ?
>
> asm/unaligned.h seems to be the toplevel header file which includes
> header files based on arch configuration. Also grepping the sources
> support that, nobody from drivers/ include access_ok.h directly.
>
Yes, you are correct!
I will send v2 patch with asm/unaligned.h
> But I can't say that I fully understand how the header files work so
> please do correct me if I have mistaken.
>
It is confusing to me as well.
There are various instances where a function used in file say for eg
int func_align (void* a)
is used and it is defined in align.h
But many files don't *directly* include align.h and rather include
any other header which includes align.h
Is compiling the file the only way to check if apppropriate header is
included or is there some other way to check for it.
Thanks
^ permalink raw reply
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