* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Amir Goldstein @ 2017-05-05 10:02 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andy Shevchenko, Dan Williams, Linux ACPI, tpmdd-devel, intel-gfx,
nouveau, linux-input, iommu, linux-mmc, Netdev, linux-pci,
USB list, alsa-devel, linux-kernel@vger.kernel.org,
Rafael J . Wysocki, Mika Westerberg, Borislav Petkov,
Jarkko Sakkinen, Jani Nikula, Ben Skeggs, Benj
In-Reply-To: <20170505095739.GB6762@lst.de>
On Fri, May 5, 2017 at 12:57 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote:
>> To complete the picture for folks not cc'ed on my patches,
>> xfs use case suggests there is also justification for the additional helpers:
>>
>> uuid_is_null() / uuid_equal()
>> guid_is_null() / guid_equal()
>
> The is_null is useful and I bet we'll find other instances. I'm
> not sure _equals really adds much value over the existing _cmp
> helpers, but on the other hand they are so trivial that we might as
> well add them.
Exactly. The fact that not only xfs used the same helper name
(drivers/md/md.c) suggests that it useful.
>
> The other thing XFS has is uuid_copy.
Andy already listed uuid_copy.
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Christoph Hellwig @ 2017-05-05 9:57 UTC (permalink / raw)
To: Amir Goldstein
Cc: alsa-devel, Heikki Krogerus, Liam Girdwood, linux-pci,
Jarkko Sakkinen, Adrian Hunter, Benjamin Tissoires,
Christoph Hellwig, Joerg Roedel, Linux ACPI, tpmdd-devel,
Ben Skeggs, nouveau, linux-mmc, Zhang Rui, Borislav Petkov,
Yisen Zhuang, Mathias Nyman, intel-gfx, linux-input, Mark Brown,
Bjorn Helgaas, Dan Williams, Andy Shevchenko
In-Reply-To: <CAOQ4uxjErce01+xyDnM=nCJS+avQ4g6hQVvH3fVotj7Ws2moCQ@mail.gmail.com>
On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote:
> To complete the picture for folks not cc'ed on my patches,
> xfs use case suggests there is also justification for the additional helpers:
>
> uuid_is_null() / uuid_equal()
> guid_is_null() / guid_equal()
The is_null is useful and I bet we'll find other instances. I'm
not sure _equals really adds much value over the existing _cmp
helpers, but on the other hand they are so trivial that we might as
well add them.
The other thing XFS has is uuid_copy.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Amir Goldstein @ 2017-05-05 9:50 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dan Williams, Linux ACPI, tpmdd-devel, intel-gfx, nouveau,
linux-input, iommu, linux-mmc, Netdev, linux-pci, USB list,
alsa-devel, linux-kernel@vger.kernel.org, Rafael J . Wysocki,
Mika Westerberg, Borislav Petkov, Jarkko Sakkinen, Jani Nikula,
Ben Skeggs, Benjamin Tissoires, Joerg
In-Reply-To: <1493976265.30052.21.camel@linux.intel.com>
On Fri, May 5, 2017 at 12:24 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote:
[...]
>> I think with this semantic change, our proposals can reach common
>> grounds
>> and satisfy a wider group of users (i.e. filesystem developers).
>>
>> Christoph also suggested a similar treatment to typedef guid_t to
>> struct uuid_le.
>> I don't know the use cases enough to comment on that.
>
> We may go this way. But I wouldn't prevent current users of uuid_le to
> continue using it without conversion (it may be done case by case after
> we settle an API)
>
> So, summarize what Christoph said it will look like
>
> typedef uuid_be uuid_t;
> typedef uuid_le guid_t
>
> uuid_cmp() / uuid_copy() / uuid_to_bin() / etc
> guid_cmp() / guid_copy() / guid_to_bin() / etc
>
> Correct? Christoph?
>
That looks right to me.
To complete the picture for folks not cc'ed on my patches,
xfs use case suggests there is also justification for the additional helpers:
uuid_is_null() / uuid_equal()
guid_is_null() / guid_equal()
Cheers,
Amir.
^ permalink raw reply
* Re: [PATCH] mac80211: Create ieee80211_if_process_skb from ieee80211_iface_work
From: Joe Perches @ 2017-05-05 9:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <1493977157.2500.2.camel@sipsolutions.net>
On Fri, 2017-05-05 at 11:39 +0200, Johannes Berg wrote:
> On Fri, 2017-05-05 at 02:34 -0700, Joe Perches wrote:
> > On Fri, 2017-05-05 at 11:06 +0200, Johannes Berg wrote:
> > > > o Use explicit casts to proper types instead of casts to (void *)
> > > > and have the compiler do the implicit cast
> > >
> > > I see no advantage in this, why? All it does is make the code
> > > longer,
> > > and if anything changes, you have to change it in multiple places
> > > now.
> >
> > It makes use of the casted to types consistent within net/mac80211
> >
> > Here are the current uses. I changed iface .c to match the others.
>
> Well, OK. I'd rather change the others I guess, don't really see the
> point.
>
> > $ grep -P --include=*.[ch] "\((\w++\s*){1,2}\s*\*\).*skb->cb" net/mac80211
> > net/mac80211/iface.c: ra_tid = (void *)&skb->cb;
> > net/mac80211/iface.c: ra_tid = (void *)&skb->cb;
> > net/mac80211/iface.c: rx_agg = (void *)&skb->cb;
> > net/mac80211/iface.c: rx_agg = (void *)&skb->cb;
> > net/mac80211/agg-tx.c: ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
> > net/mac80211/agg-tx.c: ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
> > net/mac80211/agg-rx.c: rx_agg = (struct ieee80211_rx_agg *) &skb->cb;
>
> It's really just these three that are related to the iface.c ones
> anyway.
>
> > net/mac80211/mlme.c: struct ieee80211_rx_status *rx_status = (void *) skb->cb;
> > net/mac80211/mlme.c: rx_status = (struct ieee80211_rx_status *) skb->cb;
> >
>
> These should be using IEEE80211_SKB_RXCB(skb) :)
patches welcome... :)
^ permalink raw reply
* Re: Question about SOCK_SEQPACKET
From: Steven Whitehouse @ 2017-05-05 9:45 UTC (permalink / raw)
To: Sam Kumar, linux-kernel, netdev@vger.kernel.org
In-Reply-To: <CAGtMfeCt95bj3-J5+TNb5gxVJUBDrgRjMXqMz-3jk9cOh0Z=tA@mail.gmail.com>
Hi,
On 05/05/17 06:18, Sam Kumar wrote:
> Hello,
> I have recently had occasion to use SOCK_SEQPACKET sockets on Linux,
> and noticed some odd behavior. When using sendmsg and recvmsg with
> these sockets, it seems that the "end-of-record" flag (MSG_EOR) is not
> being propagated correctly.
It depends which protocol you are using as to whether that is true.
SOCK_SEQPACKET is supposed to be identical to SOCK_STREAM except for the
record separators. That is true for DECnet (but whether DECnet is still
functional is another thing!) and not true for ax.25 which uses
SOCK_SEQPACKET incorrectly. For AF_UNIX that you are using I'm not quite
sure what would be expected.
> The man page for recvmsg(2) states:
>> The msg_flags field in the msghdr is set on return of recvmsg(). It
>> can contain several flags:
>>
>> MSG_EOR
>> indicates end-of-record; the data returned completed a record
>> (generally used with sockets of type SOCK_SEQPACKET).
>>
> The man page for recvmsg(3) states:
>> For
>> message-based sockets, such as SOCK_DGRAM and SOCK_SEQPACKET, the entire
>> message shall be read in a single operation.
>
>
> This leads me to believe that MSG_EOR should be set in the msghdr
> struct whenever recvmsg() returns data. However, I am not observing
> this flag ever being set, whether or not I set the MSG_EOR when
> sending the messages.
>
> If it helps you can take a look at the code I'm using. It is at
> https://github.com/samkumar/seqpacket-test/, commit
> 2a7dbc1f94bafce6950ee726bdd54da96945d083 (HEAD of master at the time
> of writing). Look at server.c and client.c (don't bother with
> goclient.go).
>
> The reason that I need to check MSG_EOR is that I need to distinguish
> between EOF and messages of length 0. For SOCK_STREAM sockets, a
> return value of 0 unambiguously means EOF, and for SOCK_DGRAM sockets
> a return value of 0 unambiguously means that a datagram of length 0
> was received.
>
> Because SOCK_SEQPACKET is both connection-based and message-oriented,
> a return value of 0 is ambiguous. Based on my reading of the man
> pages, reading the MSG_EOR bit would let me disambiguate between EOF
> and a zero-length datagram, because MSG_EOR would be set for a
> zero-length datagram, but would not be set for EOF.
>
> If someone could please help me understand MSG_EOR, and how to
> distinguish between EOF and zero-length messages in a SOCK_SEQPACKET
> connection, I would definitely appreciate it!
>
> Thanks,
> Sam Kumar
That would be my expectation of how it should work - if you ignore
MSG_EOR on recvmsg then what you get is identical to a SOCK_STREAM, and
that every call to recvmsg will return data from (at most) a single
message, with MSG_EOR set if the end of that message has been reached.
That is what POSIX says should happen anyway.
I do wonder if the man page for recvmsg is wrong, or at least a bit
confusing. SOCK_SEQPACKET is stream based not message based - it just
happens to have EOR markers in the stream. There is no reason that the
whole message needs to be returned in a single read, and in fact that
would be impossible if the sender didn't insert any EOR markers but kept
sending data beyond the size that the socket could buffer.
I notice that man 7 socket says SOCK_SEQPACKET is for datagrams of fixed
maximum length which is definitely wrong, as is the statement that a
consumer has to read an entire packet with each system call.
Also it is probably better to ask this question on netdev where it is
likely to get more attention from the net developers, so I'm copying my
reply there too,
Steve.
^ permalink raw reply
* Re: [PATCH] mac80211: Create ieee80211_if_process_skb from ieee80211_iface_work
From: Johannes Berg @ 2017-05-05 9:39 UTC (permalink / raw)
To: Joe Perches; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <1493976873.31950.15.camel@perches.com>
On Fri, 2017-05-05 at 02:34 -0700, Joe Perches wrote:
> On Fri, 2017-05-05 at 11:06 +0200, Johannes Berg wrote:
> > > o Use explicit casts to proper types instead of casts to (void *)
> > > and have the compiler do the implicit cast
> >
> > I see no advantage in this, why? All it does is make the code
> > longer,
> > and if anything changes, you have to change it in multiple places
> > now.
>
> It makes use of the casted to types consistent within net/mac80211
>
> Here are the current uses. I changed iface .c to match the others.
Well, OK. I'd rather change the others I guess, don't really see the
point.
> $ grep -P --include=*.[ch] "\((\w++\s*){1,2}\s*\*\).*skb->cb" net/mac80211
> net/mac80211/iface.c: ra_tid = (void *)&skb->cb;
> net/mac80211/iface.c: ra_tid = (void *)&skb->cb;
> net/mac80211/iface.c: rx_agg = (void *)&skb->cb;
> net/mac80211/iface.c: rx_agg = (void *)&skb->cb;
> net/mac80211/agg-tx.c: ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
> net/mac80211/agg-tx.c: ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
> net/mac80211/agg-rx.c: rx_agg = (struct ieee80211_rx_agg *) &skb->cb;
It's really just these three that are related to the iface.c ones
anyway.
> net/mac80211/mlme.c: struct ieee80211_rx_status *rx_status = (void *) skb->cb;
> net/mac80211/mlme.c: rx_status = (struct ieee80211_rx_status *) skb->cb;
>
These should be using IEEE80211_SKB_RXCB(skb) :)
johannes
^ permalink raw reply
* Re: [PATCH v2 net] tcp: randomize timestamps on syncookies
From: Florian Westphal @ 2017-05-05 9:36 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, David Miller, netdev, Yuchung Cheng
In-Reply-To: <1493950957.7796.36.camel@edumazet-glaptop3.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Whole point of randomization was to hide server uptime, but an attacker
> can simply start a syn flood and TCP generates 'old style' timestamps,
> directly revealing server jiffies value.
>
> Also, TSval sent by the server to a particular remote address vary
> depending on syncookies being sent or not, potentially triggering PAWS
> drops for innocent clients.
>
> Lets implement proper randomization, including for SYNcookies.
Thanks a lot Eric, this works for me (I also tested ipv6 this time ;) )
Minor nit:
net/ipv4/tcp_ipv4.c:154:6: warning: unused variable 'seq' [-Wunused-variable]
Other than this:
Reviewed-by: Florian Westphal <fw@strlen.de>
Tested-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* Re: [PATCH] mac80211: Create ieee80211_if_process_skb from ieee80211_iface_work
From: Joe Perches @ 2017-05-05 9:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <1493975178.2500.0.camel@sipsolutions.net>
On Fri, 2017-05-05 at 11:06 +0200, Johannes Berg wrote:
> > o Use explicit casts to proper types instead of casts to (void *)
> > and have the compiler do the implicit cast
>
> I see no advantage in this, why? All it does is make the code longer,
> and if anything changes, you have to change it in multiple places now.
It makes use of the casted to types consistent within net/mac80211
Here are the current uses. I changed iface .c to match the others.
$ grep -P --include=*.[ch] "\((\w++\s*){1,2}\s*\*\).*skb->cb" net/mac80211
net/mac80211/iface.c: ra_tid = (void *)&skb->cb;
net/mac80211/iface.c: ra_tid = (void *)&skb->cb;
net/mac80211/iface.c: rx_agg = (void *)&skb->cb;
net/mac80211/iface.c: rx_agg = (void *)&skb->cb;
net/mac80211/agg-tx.c: ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
net/mac80211/agg-tx.c: ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
net/mac80211/mlme.c: struct ieee80211_rx_status *rx_status = (void *) skb->cb;
net/mac80211/mlme.c: rx_status = (struct ieee80211_rx_status *) skb->cb;
net/mac80211/agg-rx.c: rx_agg = (struct ieee80211_rx_agg *) &skb->cb;
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Andy Shevchenko @ 2017-05-05 9:24 UTC (permalink / raw)
To: Amir Goldstein, Dan Williams
Cc: alsa-devel, Heikki Krogerus, Liam Girdwood, linux-pci,
Jarkko Sakkinen, Adrian Hunter, Benjamin Tissoires,
Christoph Hellwig, Joerg Roedel, Linux ACPI, tpmdd-devel,
Ben Skeggs, nouveau, linux-mmc, Zhang Rui, Borislav Petkov,
Yisen Zhuang, Mathias Nyman, intel-gfx, linux-input, Mark Brown,
Bjorn Helgaas, Mika Westerberg, Felipe Balbi, Ne
In-Reply-To: <CAOQ4uxjha8_2_HwgdgBN=G-vNytAW5Gk155E9z8OWyFiGNEZVw@mail.gmail.com>
On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote:
> On Fri, May 5, 2017 at 9:20 AM, Dan Williams <dan.j.williams@intel.com
> > wrote:
> > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > for (i = 0; i < NFIT_UUID_MAX; i++)
> > > - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16)
> > > == 0)
> > > + if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le
> > > *)spa->range_guid))
> >
> > What is _cmp_pp? Why not _compare?
Dan, it's a typo. In this patch it should be just ..._cmp(), which is
already a part of API.
> >
>
> I second that.
>
> Andy,
Amir, just to be clear. This patch can be applied without any addons to
an existing API. Above is just a typo due to rebase in my tree. I will
replace it to just uuid_le_cmp().
> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems
> code).
> The only reason I took a swing at hoisting the xfs uuid helpers is
> because it didn't
> seem like your proposal was going to be posted soon or wasn't going to
> satisfy
> the filesystems use case.
>
> My opinion now, is that your suggestion is probably much closer to the
> real deal
> than mine.
>
> IMO, you should acknowledge that the common use case for filesystems
> is
> to handle an opaque char[16] which most likely holds a uuid_be and you
> should provide 'neutral' helpers to satisfy this use case.
>
> The simplest would be to typedef uuid_t to struct uuid_be and to name
> 'neutral'
> helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my
> proposal.
> I think with this semantic change, our proposals can reach common
> grounds
> and satisfy a wider group of users (i.e. filesystem developers).
>
> Christoph also suggested a similar treatment to typedef guid_t to
> struct uuid_le.
> I don't know the use cases enough to comment on that.
We may go this way. But I wouldn't prevent current users of uuid_le to
continue using it without conversion (it may be done case by case after
we settle an API)
So, summarize what Christoph said it will look like
typedef uuid_be uuid_t;
typedef uuid_le guid_t
uuid_cmp() / uuid_copy() / uuid_to_bin() / etc
guid_cmp() / guid_copy() / guid_to_bin() / etc
Correct? Christoph?
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: net/key: slab-out-of-bounds in pfkey_compile_policy
From: Steffen Klassert @ 2017-05-05 9:11 UTC (permalink / raw)
To: Andrey Konovalov; +Cc: Herbert Xu, David S. Miller, netdev, LKML
In-Reply-To: <CAAeHK+xqxvEWMXS9sDNi2seUqFzJkijKJhivB8JDehpCJvBAaw@mail.gmail.com>
On Tue, May 02, 2017 at 06:45:03PM +0200, Andrey Konovalov wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit d3b5d35290d729a2518af00feca867385a1b08fa (4.11).
>
> A reproducer and .config are attached.
>
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in pfkey_compile_policy+0x8e6/0xd40 at
> addr ffff88006701f798
> Read of size 1280 by task a.out/4181
This bug was introduced twelve years ago...
This patch is based just on code review, I don't have an option to
function test this. But I see that we now exit with -EINVAL before the
memcpy that causes the slab-out-of-bounds when using your reproducer,
so it should at least fix the bug.
Subject: [PATCH RFC] af_key: Fix slab-out-of-bounds in pfkey_compile_policy.
The sadb_x_sec_len is stored in the unit 'byte divided by eight'.
So we have to multiply this value by eight before we can do
size checks. Otherwise we may get a slab-out-of-bounds when
we memcpy the user sec_ctx.
Fixes: df71837d502 ("[LSM-IPSec]: Security association restriction.")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/key/af_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index c1950bb..512dc43 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3285,7 +3285,7 @@ static struct xfrm_policy *pfkey_compile_policy(struct sock *sk, int opt,
p += pol->sadb_x_policy_len*8;
sec_ctx = (struct sadb_x_sec_ctx *)p;
if (len < pol->sadb_x_policy_len*8 +
- sec_ctx->sadb_x_sec_len) {
+ sec_ctx->sadb_x_sec_len*8) {
*dir = -EINVAL;
goto out;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] mac80211: Create ieee80211_if_process_skb from ieee80211_iface_work
From: Johannes Berg @ 2017-05-05 9:06 UTC (permalink / raw)
To: Joe Perches; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <401d68b9015dc036589c99a26ef4664000cc821e.1493919003.git.joe@perches.com>
> o Use explicit casts to proper types instead of casts to (void *)
> and have the compiler do the implicit cast
I see no advantage in this, why? All it does is make the code longer,
and if anything changes, you have to change it in multiple places now.
johannes
^ permalink raw reply
* how to insert new option header into ipv6 hop by hop for tx
From: JANARDHANACHARI KELLA @ 2017-05-05 8:40 UTC (permalink / raw)
To: netdev
Hi,
i wish to insert a new option like pad1, padn and rpl option into hop
by hop option payload of ipv6 transmission. how can insert into the
ipv6 module? can i get suggestion?
Thanks & Regards
--
Janardhanachari Kella
E-mail: janardhanachari.kella@smartron.com
^ permalink raw reply
* [tip:x86/urgent] x86/asm: Don't use RBP as a temporary register in csum_partial_copy_generic()
From: tip-bot for Josh Poimboeuf @ 2017-05-05 8:10 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, jpoimboe, nhorman, syzkaller, netdev, kcc,
marcelo.leitner, edumazet, torvalds, andreyknvl, mingo,
xiyou.wangcong, peterz, davem, dvyukov, tglx, vyasevich, hpa
In-Reply-To: <4b03a961efda5ec9bfe46b7b9c9ad72d1efad343.1493909486.git.jpoimboe@redhat.com>
Commit-ID: 42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6
Gitweb: http://git.kernel.org/tip/42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6
Author: Josh Poimboeuf <jpoimboe@redhat.com>
AuthorDate: Thu, 4 May 2017 09:51:40 -0500
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 5 May 2017 07:59:24 +0200
x86/asm: Don't use RBP as a temporary register in csum_partial_copy_generic()
Andrey Konovalov reported the following warning while fuzzing the kernel
with syzkaller:
WARNING: kernel stack regs at ffff8800686869f8 in a.out:4933 has bad 'bp' value c3fc855a10167ec0
The unwinder dump revealed that RBP had a bad value when an interrupt
occurred in csum_partial_copy_generic().
That function saves RBP on the stack and then overwrites it, using it as
a scratch register. That's problematic because it breaks stack traces
if an interrupt occurs in the middle of the function.
Replace the usage of RBP with another callee-saved register (R15) so
stack traces are no longer affected.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: David S . Miller <davem@davemloft.net>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Kostya Serebryany <kcc@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: linux-sctp@vger.kernel.org
Cc: netdev <netdev@vger.kernel.org>
Cc: syzkaller <syzkaller@googlegroups.com>
Link: http://lkml.kernel.org/r/4b03a961efda5ec9bfe46b7b9c9ad72d1efad343.1493909486.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/x86/lib/csum-copy_64.S | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/lib/csum-copy_64.S b/arch/x86/lib/csum-copy_64.S
index 7e48807..45a53df 100644
--- a/arch/x86/lib/csum-copy_64.S
+++ b/arch/x86/lib/csum-copy_64.S
@@ -55,7 +55,7 @@ ENTRY(csum_partial_copy_generic)
movq %r12, 3*8(%rsp)
movq %r14, 4*8(%rsp)
movq %r13, 5*8(%rsp)
- movq %rbp, 6*8(%rsp)
+ movq %r15, 6*8(%rsp)
movq %r8, (%rsp)
movq %r9, 1*8(%rsp)
@@ -74,7 +74,7 @@ ENTRY(csum_partial_copy_generic)
/* main loop. clear in 64 byte blocks */
/* r9: zero, r8: temp2, rbx: temp1, rax: sum, rcx: saved length */
/* r11: temp3, rdx: temp4, r12 loopcnt */
- /* r10: temp5, rbp: temp6, r14 temp7, r13 temp8 */
+ /* r10: temp5, r15: temp6, r14 temp7, r13 temp8 */
.p2align 4
.Lloop:
source
@@ -89,7 +89,7 @@ ENTRY(csum_partial_copy_generic)
source
movq 32(%rdi), %r10
source
- movq 40(%rdi), %rbp
+ movq 40(%rdi), %r15
source
movq 48(%rdi), %r14
source
@@ -103,7 +103,7 @@ ENTRY(csum_partial_copy_generic)
adcq %r11, %rax
adcq %rdx, %rax
adcq %r10, %rax
- adcq %rbp, %rax
+ adcq %r15, %rax
adcq %r14, %rax
adcq %r13, %rax
@@ -121,7 +121,7 @@ ENTRY(csum_partial_copy_generic)
dest
movq %r10, 32(%rsi)
dest
- movq %rbp, 40(%rsi)
+ movq %r15, 40(%rsi)
dest
movq %r14, 48(%rsi)
dest
@@ -203,7 +203,7 @@ ENTRY(csum_partial_copy_generic)
movq 3*8(%rsp), %r12
movq 4*8(%rsp), %r14
movq 5*8(%rsp), %r13
- movq 6*8(%rsp), %rbp
+ movq 6*8(%rsp), %r15
addq $7*8, %rsp
ret
^ permalink raw reply related
* Re: struct ip vs struct iphdr
From: Oleg @ 2017-05-05 8:02 UTC (permalink / raw)
To: Girish Moodalbail; +Cc: netdev
In-Reply-To: <d56b2182-3c81-5c52-5d77-8be128088e1b@oracle.com>
On Thu, May 04, 2017 at 10:08:46AM -0700, Girish Moodalbail wrote:
> Also, see this:
>
> http://stackoverflow.com/questions/42840636/difference-between-struct-ip-and-struct-iphdr
I saw this. But the answer say that struct ip and struct iphdr defined in
different places. However i see struct iphdr together with struct ip in
my netinet/ip.h. So, i thought that this answer may be inexact or incorrect.
Thanks!
--
Олег Неманов (Oleg Nemanov)
^ permalink raw reply
* Re: [Unstrung-hackers] [RFC net-next] ipv6: ext_header: add function to handle RPL extension header option 0x63
From: Andreas Bardoutsos @ 2017-05-05 7:55 UTC (permalink / raw)
To: JANARDHANACHARI KELLA
Cc: Jiri Pirko, Michael Richardson, netdev, netdev-owner,
linux-bluetooth, linux-wpan, unstrung-hackers
In-Reply-To: <CAAK7Ti9iFFqM7vMyveNfaNeCi6PmAGptXdTYgEzh2gsMptqi4w@mail.gmail.com>
Yes I think we have faced the same problem,communication with RPL
supporting devices was failing otherwise.Your patch is also more
complete since it also implements #ifdef .About the comment,yes I have
run checkpatch twice with no errors,but ok :)
Στις 2017-05-05 08:59, JANARDHANACHARI KELLA έγραψε:
> I was inserted this patch manually. It was working. on 4.9 kernel.
>
> check this bellow link for your ref.
>
> https://github.com/mwasilak/bluetooth-next/commit/f29c632ef6a6a1777815c97fd2f326faccc704f7
> [2]
>
> On Thu, May 4, 2017 at 9:30 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>
>> Thu, May 04, 2017 at 05:17:18PM CEST, bardoutsos@ceid.upatras.gr
>> wrote:
>>> Signed-off-by: Andreas Bardoutsos <bardoutsos@ceid.upatras.gr>
>>> ---
>>> Hi all!
>>>
>>> I have added a dump function(always return true) to recognise RPL
>> extension
>>> header(RFC6553)
>>> Otherwise packet was dropped by kernel resulting in failing
>> communication in
>>> RPL DAG's between
>>> linux running border routers and devices in the graph.For example
>>> communication
>>> with contiki OS running devices was previously impossible.
>>>
>>> include/uapi/linux/in6.h | 1 +
>>> net/ipv6/exthdrs.c | 13 +++++++++++++
>>> 2 files changed, 14 insertions(+)
>>>
>>> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
>>> index 46444f8fbee4..5cc12d309dfe 100644
>>> --- a/include/uapi/linux/in6.h
>>> +++ b/include/uapi/linux/in6.h
>>> @@ -146,6 +146,7 @@ struct in6_flowlabel_req {
>>> #define IPV6_TLV_CALIPSO 7 /* RFC 5570 */
>>> #define IPV6_TLV_JUMBO 194
>>> #define IPV6_TLV_HAO 201 /* home address option */
>>> +#define IPV6_TLV_RPL 99 /* RFC 6553 */
>>>
>>> /*
>>> * IPV6 socket options
>>> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
>>> index b636f1da9aec..82ed60d3180e 100644
>>> --- a/net/ipv6/exthdrs.c
>>> +++ b/net/ipv6/exthdrs.c
>>> @@ -785,6 +785,15 @@ static bool ipv6_hop_calipso(struct sk_buff
>> *skb, int
>>> optoff)
>>> return false;
>>> }
>>>
>>> +/* RPL RFC 6553 */
>>> +
>>> +static bool ipv6_hop_rpl(struct sk_buff *skb, int optoff)
>>> +{
>>> + /*Dump function which always return true
>>> + *when rpl option is detected*/
>>
>> This is definitelly wrong formatting of comment. Did you run
>> checkpatch?
>>
>>> + return true;
>>> +}
>>> +
>>> static const struct tlvtype_proc tlvprochopopt_lst[] = {
>>> {
>>> .type = IPV6_TLV_ROUTERALERT,
>>> @@ -798,6 +807,10 @@ static const struct tlvtype_proc
>> tlvprochopopt_lst[] = {
>>> .type = IPV6_TLV_CALIPSO,
>>> .func = ipv6_hop_calipso,
>>> },
>>> + {
>>> + .type = IPV6_TLV_RPL,
>>> + .func = ipv6_hop_rpl,
>>> + },
>>> { -1, }
>>> };
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-wpan" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> [1]
>
> --
>
> Sincerely Your's
>
> Janardhanachari Kella
>
> Contact:+91-9908469599
> E-mail: eni.chari@gmail.com
>
>
> Links:
> ------
> [1] http://vger.kernel.org/majordomo-info.html
> [2]
> https://github.com/mwasilak/bluetooth-next/commit/f29c632ef6a6a1777815c97fd2f326faccc704f7
>
> _______________________________________________
> Unstrung-hackers mailing list
> Unstrung-hackers@lists.sandelman.ca
> https://lists.sandelman.ca/mailman/listinfo/unstrung-hackers
^ permalink raw reply
* Re: struct ip vs struct iphdr
From: Oleg @ 2017-05-05 7:48 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: netdev
In-Reply-To: <20170504165248.GI7300@oracle.com>
On Thu, May 04, 2017 at 12:52:48PM -0400, Sowmini Varadhan wrote:
> BSD vs linux?
>
> struct ip is a BSD-ism, intended to be used if you were porting
> some BSD app.
Thanks!
--
Олег Неманов (Oleg Nemanov)
^ permalink raw reply
* Re: [PATCH] iproute2: hide devices starting with period by default
From: Nicolas Dichtel @ 2017-05-05 7:42 UTC (permalink / raw)
To: David Ahern, Florian Fainelli; +Cc: David Miller, stephen, netdev
In-Reply-To: <01aa60dc-8bf2-3207-1abe-158100f52960@gmail.com>
Le 04/05/2017 à 21:47, David Ahern a écrit :
> On 5/4/17 1:10 PM, Florian Fainelli wrote:
>> On 05/04/2017 09:37 AM, David Ahern wrote:
>>> On 5/4/17 9:15 AM, Nicolas Dichtel wrote:
>>>> Le 24/02/2017 à 16:52, David Ahern a écrit :
>>>>> On 2/23/17 8:12 PM, David Miller wrote:
>>>>>> This really need to be a fundamental facility, so that it transparently
>>>>>> works for NetworkManager, router daemons, everything. Not just iproute2
>>>>>> and "ls".
>>>>>
>>>>> I'll rebase my patch and send out as RFC.
>>>>>
>>>> David, did you finally send those patches?
>>>>
>>>
>>> No, but for a few reasons.
>>>
>>> It is easy to hide devices in a dump:
>>>
>>> https://github.com/dsahern/linux/commit/48a80a00eac284e58bae04af10a5a932dd7aee00
>>>
>>>
>>> But I think those devices should also not exist in sysfs or procfs which
>>> overlaps what I would like to see for lightweight netdevices:
>>>
>>> https://github.com/dsahern/linux/commit/70574be699cf252e77f71e3df11192438689f976
>>
>> Interesting that does indeed solve the same problems as the L2 only
>> patch set intended. I am not exactly sure if hiding the devices from
>> procfs/sysfs would be appropriate in my case (dumb L2 only switch that
>> only does 802.1q for instance), but why not.
>>
>>
>>>
>>>
>>> and to be complete, hidden devices should not be allowed to have a
>>> network address or transmit packets which is the L2 only intent from
>>> Florian:
>>> https://www.spinics.net/lists/netdev/msg340808.html
>>>
>>
>> Do you plan on submitting the LWT patch set at some point?
>
> Definitely. Maybe I can find some time this weekend.
>
Ok, thank you for the details.
I agree with Jiri that the name should be something different than lwt.
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Christoph Hellwig @ 2017-05-05 7:30 UTC (permalink / raw)
To: Amir Goldstein
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Heikki Krogerus, Liam Girdwood,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Jarkko Sakkinen, Adrian Hunter,
Benjamin Tissoires, Christoph Hellwig, Linux ACPI,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Ben Skeggs,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Zhang Rui, Borislav Petkov,
Yisen Zhuang, Mathias Nyman,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-input-u79uwXL29TY76Z2rM5mHXA, Jani Nikula, Mark Brown,
Bjorn Helgaas, Dan Williams, Andy Shevchenko <andriy.shevchenk
In-Reply-To: <CAOQ4uxjha8_2_HwgdgBN=G-vNytAW5Gk155E9z8OWyFiGNEZVw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, May 05, 2017 at 10:06:06AM +0300, Amir Goldstein wrote:
> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems code).
Yeah.
> IMO, you should acknowledge that the common use case for filesystems is
> to handle an opaque char[16] which most likely holds a uuid_be and you
> should provide 'neutral' helpers to satisfy this use case.
>
> The simplest would be to typedef uuid_t to struct uuid_be and to name 'neutral'
> helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my proposal.
It's not jut neutral, it's the right thing to to. The Apollo / DCE
uuids (later also specified in RFC 4122) are big endian, so we should
use the name there.
> Christoph also suggested a similar treatment to typedef guid_t to
> struct uuid_le.
Exactly. The whole idea of "little endian UUIDs" comes from the
Wintel world, and if you look at the relevant specs they are almost
exclusively referred to as GUIDs.
The magic XFS and AFS types for specific interpretations of one of
the RFC4122 formats don't really help, but I'll just send a patch
to kill them off for XFS ASAP to at least get that out, and we
probably should revert at least
"afs: Move UUID struct to linux/uuid.h"
That moved the AFS mess to common code as a start, and then
also clean up the way we generate random UUIDs, where we currently
have le helper, a be helper and then also generate_random_uuid
just to confuse the heck out of people. With no description of
either of them.
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Amir Goldstein @ 2017-05-05 7:06 UTC (permalink / raw)
To: Dan Williams
Cc: Andy Shevchenko, Linux ACPI, tpmdd-devel, intel-gfx, nouveau,
linux-input, iommu, linux-mmc, Netdev, linux-pci, USB list,
alsa-devel, linux-kernel@vger.kernel.org, Rafael J . Wysocki,
Mika Westerberg, Borislav Petkov, Jarkko Sakkinen, Jani Nikula,
Ben Skeggs, Benjamin Tissoires
In-Reply-To: <CAPcyv4jzD0MEBRNTwTokVzgdDWas682ArUjRAGT1hp=QRE8Pjg@mail.gmail.com>
On Fri, May 5, 2017 at 9:20 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
>> bytes. Instead we convert them to use uuid_le type. At the same time we
>> convert current users.
>>
>> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
>> get rid of it.
>>
>> The conversion fixes a potential bug in int340x_thermal as well since
>> we have to use memcmp() on binary data.
>>
>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
>> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
>> Cc: Borislav Petkov <bp@suse.de>
>> Cc: Dan Williams <dan.j.williams@intel.com>
>> Cc: Amir Goldstein <amir73il@gmail.com>
>> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>> Cc: Ben Skeggs <bskeggs@redhat.com>
>> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>> Cc: Joerg Roedel <joro@8bytes.org>
>> Cc: Adrian Hunter <adrian.hunter@intel.com>
>> Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: Felipe Balbi <balbi@kernel.org>
>> Cc: Mathias Nyman <mathias.nyman@intel.com>
>> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>> Cc: Liam Girdwood <lgirdwood@gmail.com>
>> Cc: Mark Brown <broonie@kernel.org>
>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> [..]
>> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
>> index 0f7982a1caaf..bd3e45ede056 100644
>> --- a/drivers/acpi/nfit/core.c
>> +++ b/drivers/acpi/nfit/core.c
>> @@ -74,11 +74,11 @@ struct nfit_table_prev {
>> struct list_head flushes;
>> };
>>
>> -static u8 nfit_uuid[NFIT_UUID_MAX][16];
>> +static uuid_le nfit_uuid[NFIT_UUID_MAX];
>>
>> -const u8 *to_nfit_uuid(enum nfit_uuids id)
>> +const uuid_le *to_nfit_uuid(enum nfit_uuids id)
>> {
>> - return nfit_uuid[id];
>> + return &nfit_uuid[id];
>> }
>> EXPORT_SYMBOL(to_nfit_uuid);
>>
>> @@ -207,7 +207,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
>> u32 offset, fw_status = 0;
>> acpi_handle handle;
>> unsigned int func;
>> - const u8 *uuid;
>> + const uuid_le *uuid;
>> int rc, i;
>>
>> func = cmd;
>> @@ -394,7 +394,7 @@ int nfit_spa_type(struct acpi_nfit_system_address *spa)
>> int i;
>>
>> for (i = 0; i < NFIT_UUID_MAX; i++)
>> - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0)
>> + if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le *)spa->range_guid))
>
> What is _cmp_pp? Why not _compare?
>
I second that.
Andy,
I much rather that you sort out uuid helpers in a way that will
satisfy the filesystem
needs (just provide the helpers don't need to convert filesystems code).
The only reason I took a swing at hoisting the xfs uuid helpers is
because it didn't
seem like your proposal was going to be posted soon or wasn't going to satisfy
the filesystems use case.
My opinion now, is that your suggestion is probably much closer to the real deal
than mine.
IMO, you should acknowledge that the common use case for filesystems is
to handle an opaque char[16] which most likely holds a uuid_be and you
should provide 'neutral' helpers to satisfy this use case.
The simplest would be to typedef uuid_t to struct uuid_be and to name 'neutral'
helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my proposal.
I think with this semantic change, our proposals can reach common grounds
and satisfy a wider group of users (i.e. filesystem developers).
Christoph also suggested a similar treatment to typedef guid_t to
struct uuid_le.
I don't know the use cases enough to comment on that.
Cheers,
Amir.
^ permalink raw reply
* Re: [RFC iproute2 0/8] RDMA tool
From: Jiri Benc @ 2017-05-05 6:54 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Stephen Hemminger, Doug Ledford, Leon Romanovsky, Jiri Pirko,
Ariel Almog, Dennis Dalessandro, Ram Amrani, Bart Van Assche,
Sagi Grimberg, Jason Gunthorpe, Christoph Hellwig, Or Gerlitz,
Linux RDMA, Linux Netdev
In-Reply-To: <20170504180216.7665-1-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Thu, 4 May 2017 21:02:08 +0300, Leon Romanovsky wrote:
> In order to close object model, ensure reuse of existing code and make this
> tool usable from day one, we decided to implement wrappers over legacy sysfs
> prior to implementing netlink functionality. As a nice bonus, it will allow
> to use this tool with old kernels too.
This sounds wrong. We don't support legacy ioctl interface for the 'ip'
command, either. I think rdma should be converted to netlink first and
the new tool should only use netlink.
Jiri
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] iproute2: hide devices starting with period by default
From: Jiri Benc @ 2017-05-05 6:47 UTC (permalink / raw)
To: David Ahern
Cc: Florian Fainelli, nicolas.dichtel, David Miller, stephen, netdev
In-Reply-To: <01aa60dc-8bf2-3207-1abe-158100f52960@gmail.com>
On Thu, 4 May 2017 13:47:36 -0600, David Ahern wrote:
> On 5/4/17 1:10 PM, Florian Fainelli wrote:
> > On 05/04/2017 09:37 AM, David Ahern wrote:
> > Do you plan on submitting the LWT patch set at some point?
>
> Definitely. Maybe I can find some time this weekend.
I suggest to change the name to "lwd" or so. "lwt" name is too similar
to the existing "lwtunnel" infrastructure and would be very confusing.
Thanks,
Jiri
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Dan Williams @ 2017-05-05 6:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: alsa-devel, Heikki Krogerus, Liam Girdwood, linux-pci,
Amir Goldstein, Jarkko Sakkinen, Adrian Hunter,
Benjamin Tissoires, Joerg Roedel, Linux ACPI, tpmdd-devel,
Ben Skeggs, nouveau, linux-mmc, Zhang Rui, Borislav Petkov,
Yisen Zhuang, Mathias Nyman, intel-gfx, linux-input, Mark Brown,
Bjorn Helgaas, Mika Westerberg, Felipe Balbi
In-Reply-To: <20170504092151.88646-1-andriy.shevchenko@linux.intel.com>
On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Amir Goldstein <amir73il@gmail.com>
> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Felipe Balbi <balbi@kernel.org>
> Cc: Mathias Nyman <mathias.nyman@intel.com>
> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[..]
> diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
> index 0f7982a1caaf..bd3e45ede056 100644
> --- a/drivers/acpi/nfit/core.c
> +++ b/drivers/acpi/nfit/core.c
> @@ -74,11 +74,11 @@ struct nfit_table_prev {
> struct list_head flushes;
> };
>
> -static u8 nfit_uuid[NFIT_UUID_MAX][16];
> +static uuid_le nfit_uuid[NFIT_UUID_MAX];
>
> -const u8 *to_nfit_uuid(enum nfit_uuids id)
> +const uuid_le *to_nfit_uuid(enum nfit_uuids id)
> {
> - return nfit_uuid[id];
> + return &nfit_uuid[id];
> }
> EXPORT_SYMBOL(to_nfit_uuid);
>
> @@ -207,7 +207,7 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm,
> u32 offset, fw_status = 0;
> acpi_handle handle;
> unsigned int func;
> - const u8 *uuid;
> + const uuid_le *uuid;
> int rc, i;
>
> func = cmd;
> @@ -394,7 +394,7 @@ int nfit_spa_type(struct acpi_nfit_system_address *spa)
> int i;
>
> for (i = 0; i < NFIT_UUID_MAX; i++)
> - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16) == 0)
> + if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le *)spa->range_guid))
What is _cmp_pp? Why not _compare?
Other than that, looks ok to me.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: kbuild test robot @ 2017-05-05 6:04 UTC (permalink / raw)
To: Andy Shevchenko
Cc: alsa-devel, Heikki Krogerus, Liam Girdwood, linux-pci,
Amir Goldstein, Jarkko Sakkinen, Adrian Hunter,
Benjamin Tissoires, Joerg Roedel, linux-acpi, tpmdd-devel,
Ben Skeggs, nouveau, linux-mmc, Zhang Rui, Borislav Petkov,
Yisen Zhuang, Mathias Nyman, intel-gfx, linux-input, Mark Brown,
Bjorn Helgaas, Dan Williams, Andy Shevchenko
In-Reply-To: <20170504092151.88646-1-andriy.shevchenko@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]
Hi Andy,
[auto build test ERROR on next-20170503]
[cannot apply to pm/linux-next linus/master linux/master v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andy-Shevchenko/ACPI-Switch-to-use-generic-UUID-API/20170505-134225
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from init/main.c:29:0:
>> include/linux/acpi.h:744:16: error: unknown type name 'uuid_le'
const uuid_le *uuid,
^~~~~~~
vim +/uuid_le +744 include/linux/acpi.h
738 const struct device_driver *drv)
739 {
740 return false;
741 }
742
743 static inline union acpi_object *acpi_evaluate_dsm(acpi_handle handle,
> 744 const uuid_le *uuid,
745 int rev, int func,
746 union acpi_object *argv4)
747 {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6568 bytes --]
[-- Attachment #3: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* SSE instructions for fast packet copy?
From: Tom Herbert @ 2017-05-05 5:50 UTC (permalink / raw)
To: Linux Kernel Network Developers
Hi,
I am thinking about the possibility of using SSE in kernel for
speeding up the kernel memcpy particularly for copy to userspace
emeory, and maybe even using the string instructions (like if we
supported regex in something like eBPF). AFAIK we don't use SSE in
kernel because of xmm register state needing to be saved across
context switch. However, if we start busy-polling a CPU in kernel on
network queues then there might not be any context switches to worry
about. In this model we'd want to enable SSE per CPU.
Has this ever been tried before? Is this at all feasible? :-) Is it
possible to enable SSE for kernel for just one CPU? (I found CPUID
will return SSE supported, but don't see how to enable other than
-msse for compiling).
Thanks,
Tom
^ permalink raw reply
* Re: Bug in skb_gro_receive - possible bad page state problems?
From: Eric Dumazet @ 2017-05-05 4:14 UTC (permalink / raw)
To: Anand H. Krishnan; +Cc: netdev
In-Reply-To: <CACeb84vFNfPcC=FJ3HEjraZ02Zi2igbK0Q=M3=pUw7AKG=u3PQ@mail.gmail.com>
On Fri, 2017-05-05 at 08:57 +0530, Anand H. Krishnan wrote:
> Hello,
>
> Is skb_gro_receive doing the right thing for cloned packets?
>
> When we are merging fragments, we do not seem to be taking a reference
> to the underlying page. To me, it looks like it should work fine for non-cloned
> packets. However, for cloned packets, when the gro-ed packet is eventually
> freed (because the original skb was not cloned and hence reference was 1),
> the merged skb's frags also get freed (put_page-ed) without taking into account
> the other references that were held for the fragments (dataref).
>
> We saw crashes because of this behavior. Our setup had a third party kernel
> forwarding module which uses GRO (napi_gro_receive). Doing iperf3 with small
> packets and doing tcpdump on the receiving tap interface results in the problem.
> With DEBUG_VM enabled, put page crashes. Without DEBUG_VM, bad page
> state results.
Yep, GRO must not be used with cloned skb.
This is why gro_cells_receive() has this check :
if (!gcells->cells || skb_cloned(skb) || netif_elide_gro(dev))
return netif_rx(skb);
(But not the main napi_gro_receive() that is supposed to be used by
driver before any tap)
^ 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