* devlink dump of mlxsw_adj table triggers a panic
From: David Ahern @ 2017-10-04 23:57 UTC (permalink / raw)
To: Arkadi Sharshevsky, Jiri Pirko; +Cc: netdev@vger.kernel.org
The following devlink command on a 2700 triggers a panic every time.
Kernel is net-next at 26873308b21654b6e0785b9f9e2c5414d37a4c4c
$ devlink dpipe table dump pci/0000:03:00.0 name mlxsw_adj
devlink answers: No buffer space available
<hang>
I have seen several different stack traces and varying amounts of EMAD
errors on console:
[ 77.453364] mlxsw_spectrum 0000:03:00.0: EMAD reg access failed
(tid=64c24a400003688,reg_id=200b(sfn),type=query,status=0(operation
performed))
[ 77.466568] mlxsw_spectrum 0000:03:00.0: Failed to get FDB notifications
If it does not reproduce for you let me know and I'll grab a trace.
David
^ permalink raw reply
* mailing list archive
From: Jerry Snitselaar @ 2017-10-04 23:56 UTC (permalink / raw)
To: linux-integrity
Is there an archive set up for the list? I've
been catching up on email and just found out
about the move.
^ permalink raw reply
* Re: [PATCH 4/5] bcache: writeback: collapse contiguous IO better
From: Michael Lyle @ 2017-10-04 23:54 UTC (permalink / raw)
To: Coly Li; +Cc: Junhui Tang, linux-bcache, linux-block, Kent Overstreet
In-Reply-To: <2c39cd9c-34bd-5982-9fd7-ceb61305c13d@coly.li>
Coly---
Thanks for running these tests.
The change is expected to improve performance when the application
writes to many adjacent blocks, out of order. Many database workloads
are like this. My VM provisioning / installation / cleanup workloads
have a lot of this, too.
I believe that it really has nothing to do with how full the cache
device is, or whether things are contiguous on the cache device. It
has to do with what proportion of the data is contiguous on the
**backing device**.
To get the best example of this from fio, the working set size, for
write, needs to be less than half the size of the cache (otherwise,
previous writebacks make "holes" in the middle of the data that will
make things from being contiguous), but large enough to trigger
writeback. It may help in other circumstances, but the performance
measurement will be much more random (it effectively depends on where
the writeback cursor is in its cycle).
I'm not surprised that peak writeback rate on very fast backing
devices will probably be a little less-- we only try to writeback 64
things at a time; and NCQ queue depths are 32 or so-- so across a
parallel RAID0 installation the drives will not have their queues
filled entirely already. Waiting for blocks to be in order will make
the queues even less full. However, they'll be provided with I/O in
LBA order, so presumably the IO utilization and latency will be better
during this. Plugging will magnify these effects-- it will write back
faster when there's contiguous data and utilize the devices more
efficiently,
We could add a tunable for the writeback semaphore size if it's
desired to have more than 64 things in flight-- of course, we can't
have too many because dirty extents are currently selected from a pool
of maximum 500.
Mike
On Wed, Oct 4, 2017 at 11:43 AM, Coly Li <i@coly.li> wrote:
> On 2017/10/2 =E4=B8=8A=E5=8D=881:34, Michael Lyle wrote:
>> On Sun, Oct 1, 2017 at 10:23 AM, Coly Li <i@coly.li> wrote:
>>> Hi Mike,
>>>
>>> Your data set is too small. Normally bcache users I talk with, they use
>>> bcache for distributed storage cluster or commercial data base, their
>>> catch device is large and fast. It is possible we see different I/O
>>> behaviors because we use different configurations.
>>
>> A small dataset is sufficient to tell whether the I/O subsystem is
>> successfully aggregating sequential writes or not. :P It doesn't
>> matter whether the test is 10 minutes or 10 hours... The writeback
>> stuff walks the data in order. :P
>
> Hi Mike,
>
> I test your patch4,5 all these days, it turns out that your patch works
> better when dirty data is full on cache device. And I can say it works
> perfectly when dirty data is full on cache device and backing cached
> device is a single spinning hard disk.
>
> It is not because your data set is full, it is because when your data
> set is small, the cache can be close to full state, then there is more
> possibility to have adjacent dirty data blocks to writeback.
>
> In the best case of your patch4,5, dirty data full on cache device and
> cached device is a single spinning hard disk, writeback performance can
> be 2x faster when there is no front end I/O. See one of the performmance
> data (the lower the better)
> http://blog.coly.li/wp-content/uploads/2017/10/existing_dirty_data_on_cac=
he_single_disk_1T_full_cache.png
>
>
>
> When the backing cached device gets faster and faster, your patch4,5
> performs less and less advantage.
>
> For same backing cached device size, when cache device gets smaller and
> smaller, your patch4,5 performs less and less advantage.
>
> And in the following configuration I find current bcache code performs
> better (not too much) then your patch4,5 reorder method,
> - cached device: A md linear device combined by 2x1.8T hard disks
> - cache device: A 1800G NVMe SSD
> - fio rand write blocksize 512K
> - dirty data occupies 50% space of cache device (900G from 1800G)
> One of the performance data can be found here,
> http://blog.coly.li/wp-content/uploads/2017/10/existing_dirty_data_on_ssd=
_900_1800G_cache_half.png
>
>>
>> ***We are measuring whether the cache and I/O scheduler can correctly
>> order up-to-64-outstanding writebacks from a chunk of 500 dirty
>> extents-- we do not need to do 12 hours of writes first to measure
>> this.***
>>
>> It's important that there be actual contiguous data, though, or the
>> difference will be less significant. If you write too much, there
>> will be a lot more holes in the data from writeback during the test
>> and from writes bypassing the cache.
>>
>
> I see, your patches do perform better when dirty data are contiguous on
> SSD. But we should know how much the probability in real world this
> assumption can be real. Especially in some cases, your patches make
> writeback performance slower than current bcache code does.
>
> To test your patches, the following backing devices are used,
> - md raid5 device composed by 4 hard disks
> - md linear device composed by 2 hard disks
> - md raid0 devices composed by 4 hard disks
> - single 250G SATA SSD
> - single 1.8T hard disk
>
> And the following cache devices are used,
> - 3.8T NVMe SSD
> - 1.8T NVMe SSD partition
> - 232G NVMe SSD partition
>
>> Having all the data to writeback be sequential is an
>> artificial/synthetic condition that allows the difference to be
>> measured more easily. It's about a 2x difference under these
>> conditions in my test environment. I expect with real data that is
>> not purely sequential it's more like a few percent.
>
> From my test, it seems in the following situation your patches4,5 works
> better,
> 1) backing cached device is slow
> 2.1) higher percentage of (cache_device_size/cached_device_size), this
> means dirty data on cache device has more probability to be contiguous.
> or 2.2) dirty data on cache device is almost full
>
> This is what I observe in these days testing. I will continue to try
> tomorrow to see in which percentage of dirty data on cache device when
> current bcache code performs worse than your patch. So far I see when
> cache is 50% full, and cache device is half size of cached device, your
> patch4,5 won't have performance advantage, in my testing environment.
>
> All performance comparison png files are too big, once I finish the
> final benchmark, I will combine them into a pdf file and share a link.
>
> Thanks.
>
> --
> Coly Li
^ permalink raw reply
* Re: [PATCH 4/5] bcache: writeback: collapse contiguous IO better
From: Michael Lyle @ 2017-10-04 23:54 UTC (permalink / raw)
To: Coly Li; +Cc: Junhui Tang, linux-bcache, linux-block, Kent Overstreet
In-Reply-To: <2c39cd9c-34bd-5982-9fd7-ceb61305c13d@coly.li>
Coly---
Thanks for running these tests.
The change is expected to improve performance when the application
writes to many adjacent blocks, out of order. Many database workloads
are like this. My VM provisioning / installation / cleanup workloads
have a lot of this, too.
I believe that it really has nothing to do with how full the cache
device is, or whether things are contiguous on the cache device. It
has to do with what proportion of the data is contiguous on the
**backing device**.
To get the best example of this from fio, the working set size, for
write, needs to be less than half the size of the cache (otherwise,
previous writebacks make "holes" in the middle of the data that will
make things from being contiguous), but large enough to trigger
writeback. It may help in other circumstances, but the performance
measurement will be much more random (it effectively depends on where
the writeback cursor is in its cycle).
I'm not surprised that peak writeback rate on very fast backing
devices will probably be a little less-- we only try to writeback 64
things at a time; and NCQ queue depths are 32 or so-- so across a
parallel RAID0 installation the drives will not have their queues
filled entirely already. Waiting for blocks to be in order will make
the queues even less full. However, they'll be provided with I/O in
LBA order, so presumably the IO utilization and latency will be better
during this. Plugging will magnify these effects-- it will write back
faster when there's contiguous data and utilize the devices more
efficiently,
We could add a tunable for the writeback semaphore size if it's
desired to have more than 64 things in flight-- of course, we can't
have too many because dirty extents are currently selected from a pool
of maximum 500.
Mike
On Wed, Oct 4, 2017 at 11:43 AM, Coly Li <i@coly.li> wrote:
> On 2017/10/2 上午1:34, Michael Lyle wrote:
>> On Sun, Oct 1, 2017 at 10:23 AM, Coly Li <i@coly.li> wrote:
>>> Hi Mike,
>>>
>>> Your data set is too small. Normally bcache users I talk with, they use
>>> bcache for distributed storage cluster or commercial data base, their
>>> catch device is large and fast. It is possible we see different I/O
>>> behaviors because we use different configurations.
>>
>> A small dataset is sufficient to tell whether the I/O subsystem is
>> successfully aggregating sequential writes or not. :P It doesn't
>> matter whether the test is 10 minutes or 10 hours... The writeback
>> stuff walks the data in order. :P
>
> Hi Mike,
>
> I test your patch4,5 all these days, it turns out that your patch works
> better when dirty data is full on cache device. And I can say it works
> perfectly when dirty data is full on cache device and backing cached
> device is a single spinning hard disk.
>
> It is not because your data set is full, it is because when your data
> set is small, the cache can be close to full state, then there is more
> possibility to have adjacent dirty data blocks to writeback.
>
> In the best case of your patch4,5, dirty data full on cache device and
> cached device is a single spinning hard disk, writeback performance can
> be 2x faster when there is no front end I/O. See one of the performmance
> data (the lower the better)
> http://blog.coly.li/wp-content/uploads/2017/10/existing_dirty_data_on_cache_single_disk_1T_full_cache.png
>
>
>
> When the backing cached device gets faster and faster, your patch4,5
> performs less and less advantage.
>
> For same backing cached device size, when cache device gets smaller and
> smaller, your patch4,5 performs less and less advantage.
>
> And in the following configuration I find current bcache code performs
> better (not too much) then your patch4,5 reorder method,
> - cached device: A md linear device combined by 2x1.8T hard disks
> - cache device: A 1800G NVMe SSD
> - fio rand write blocksize 512K
> - dirty data occupies 50% space of cache device (900G from 1800G)
> One of the performance data can be found here,
> http://blog.coly.li/wp-content/uploads/2017/10/existing_dirty_data_on_ssd_900_1800G_cache_half.png
>
>>
>> ***We are measuring whether the cache and I/O scheduler can correctly
>> order up-to-64-outstanding writebacks from a chunk of 500 dirty
>> extents-- we do not need to do 12 hours of writes first to measure
>> this.***
>>
>> It's important that there be actual contiguous data, though, or the
>> difference will be less significant. If you write too much, there
>> will be a lot more holes in the data from writeback during the test
>> and from writes bypassing the cache.
>>
>
> I see, your patches do perform better when dirty data are contiguous on
> SSD. But we should know how much the probability in real world this
> assumption can be real. Especially in some cases, your patches make
> writeback performance slower than current bcache code does.
>
> To test your patches, the following backing devices are used,
> - md raid5 device composed by 4 hard disks
> - md linear device composed by 2 hard disks
> - md raid0 devices composed by 4 hard disks
> - single 250G SATA SSD
> - single 1.8T hard disk
>
> And the following cache devices are used,
> - 3.8T NVMe SSD
> - 1.8T NVMe SSD partition
> - 232G NVMe SSD partition
>
>> Having all the data to writeback be sequential is an
>> artificial/synthetic condition that allows the difference to be
>> measured more easily. It's about a 2x difference under these
>> conditions in my test environment. I expect with real data that is
>> not purely sequential it's more like a few percent.
>
> From my test, it seems in the following situation your patches4,5 works
> better,
> 1) backing cached device is slow
> 2.1) higher percentage of (cache_device_size/cached_device_size), this
> means dirty data on cache device has more probability to be contiguous.
> or 2.2) dirty data on cache device is almost full
>
> This is what I observe in these days testing. I will continue to try
> tomorrow to see in which percentage of dirty data on cache device when
> current bcache code performs worse than your patch. So far I see when
> cache is 50% full, and cache device is half size of cached device, your
> patch4,5 won't have performance advantage, in my testing environment.
>
> All performance comparison png files are too big, once I finish the
> final benchmark, I will combine them into a pdf file and share a link.
>
> Thanks.
>
> --
> Coly Li
^ permalink raw reply
* Re: [PATCH 2/3 v2] net: phy: DP83822 initial driver submission
From: Andrew Lunn @ 2017-10-04 23:53 UTC (permalink / raw)
To: Woojung.Huh; +Cc: dmurphy, f.fainelli, netdev, afd
In-Reply-To: <9235D6609DB808459E95D78E17F2E43D40B3F9A9@CHN-SV-EXMX02.mchp-main.com>
On Wed, Oct 04, 2017 at 10:44:36PM +0000, Woojung.Huh@microchip.com wrote:
> > +static int dp83822_suspend(struct phy_device *phydev)
> > +{
> > + int value;
> > +
> > + mutex_lock(&phydev->lock);
> > + value = phy_read_mmd(phydev, DP83822_DEVADDR,
> > MII_DP83822_WOL_CFG);
> > + mutex_unlock(&phydev->lock);
> Would we need mutex to access phy_read_mmd()?
> phy_read_mmd() has mdio_lock for indirect access.
Hi Woojung
The mdio lock is not sufficient. It protects against two mdio
accesses. But here we need to protect against two phy operations.
There is a danger something else tries to access the phy during
suspend.
> > + if (!(value & DP83822_WOL_EN))
> > + genphy_suspend(phydev);
Releasing the lock before calling genphy_suspend() is not so nice.
Maybe add a version which assumes the lock has already been taken?
Andrew
^ permalink raw reply
* [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes
From: Heinrich Schuchardt @ 2017-10-04 23:53 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAF6AEGtJfdb-TMd5_iZqzmwqvEzsJG2jp5y+D10oEH9y7ke8Xw@mail.gmail.com>
On 10/05/2017 01:19 AM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> On 10/04/2017 10:54 PM, Rob Clark wrote:
>>> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>> On 09/10/2017 03:22 PM, Rob Clark wrote:
>>>>> Shell.efi uses this, and supporting color attributes makes things look
>>>>> nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
>>>>> Not all colors have a perfect match, but spec just says "Devices
>>>>> supporting a different number of text colors are required to emulate the
>>>>> above colors to the best of the device’s capabilities".
>>>>>
>>>>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>>>>> ---
>>>>> include/efi_api.h | 29 +++++++++++++++++++++++++++++
>>>>> lib/efi_loader/efi_console.c | 30 ++++++++++++++++++++++++++++++
>>>>> 2 files changed, 59 insertions(+)
>>>>>
>>>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>>>> index 87c8ffe68e..3cc1dbac2e 100644
>>>>> --- a/include/efi_api.h
>>>>> +++ b/include/efi_api.h
>>>>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>>>> EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>>>> 0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>>>>
>>>>> +#define EFI_BLACK 0x00
>>>>> +#define EFI_BLUE 0x01
>>>>> +#define EFI_GREEN 0x02
>>>>> +#define EFI_CYAN 0x03
>>>>> +#define EFI_RED 0x04
>>>>> +#define EFI_MAGENTA 0x05
>>>>> +#define EFI_BROWN 0x06
>>>>> +#define EFI_LIGHTGRAY 0x07
>>>>> +#define EFI_BRIGHT 0x08
>>>>> +#define EFI_DARKGRAY 0x08
>>>>> +#define EFI_LIGHTBLUE 0x09
>>>>> +#define EFI_LIGHTGREEN 0x0a
>>>>> +#define EFI_LIGHTCYAN 0x0b
>>>>> +#define EFI_LIGHTRED 0x0c
>>>>> +#define EFI_LIGHTMAGENTA 0x0d
>>>>> +#define EFI_YELLOW 0x0e
>>>>> +#define EFI_WHITE 0x0f
>>>>> +#define EFI_BACKGROUND_BLACK 0x00
>>>>> +#define EFI_BACKGROUND_BLUE 0x10
>>>>> +#define EFI_BACKGROUND_GREEN 0x20
>>>>> +#define EFI_BACKGROUND_CYAN 0x30
>>>>> +#define EFI_BACKGROUND_RED 0x40
>>>>> +#define EFI_BACKGROUND_MAGENTA 0x50
>>>>> +#define EFI_BACKGROUND_BROWN 0x60
>>>>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>>>
>>>> Will we ever use these constants?
>>>>
>>>
>>> possibly not, but it is useful to understand what is going on with
>>> efi->ansi mapping, so I would prefer to keep them.
>>>
>>>>
>>>> Where are the comments explaining the defines below?
>>>>
>>>>> +
>>>>> +#define EFI_ATTR_FG(attr) ((attr) & 0x0f)
>>>>
>>>> This saves 8 entries in the table below.
>>>> +#define EFI_ATTR_FG(attr) ((attr) & 0x07)
>>>>
>>>>> +#define EFI_ATTR_BG(attr) (((attr) >> 4) & 0x7)
>>>>
>>>> Add
>>>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>>>
>>>>> +
>>>>> struct efi_simple_text_output_protocol {
>>>>> void *reset;
>>>>> efi_status_t (EFIAPI *output_string)(
>>>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>>>> index 2e13fdc096..fcd65ca488 100644
>>>>> --- a/lib/efi_loader/efi_console.c
>>>>> +++ b/lib/efi_loader/efi_console.c
>>>>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>>>>> return EFI_EXIT(EFI_SUCCESS);
>>>>> }
>>>>>
>>>>> +static const struct {
>>>>> + unsigned fg;
>>>>> + unsigned bg;
>>>>> +} color[] = {
>>>>> + { 30, 40 }, /* 0: black */
>>>>> + { 34, 44 }, /* 1: blue */
>>>>> + { 32, 42 }, /* 2: green */
>>>>> + { 36, 46 }, /* 3: cyan */
>>>>> + { 31, 41 }, /* 4: red */
>>>>> + { 35, 45 }, /* 5: magenta */
>>>>> + { 30, 40 }, /* 6: brown, map to black */
>>>>
>>>> This should be { 33, 43 }
>>>>
>>>>> + { 37, 47 }, /* 7: light grey, map to white */
>>>>
>>>> The entries below are redundant.
>>>>
>>>>> + { 37, 47 }, /* 8: bright, map to white */
>>>>> + { 34, 44 }, /* 9: light blue, map to blue */
>>>>> + { 32, 42 }, /* A: light green, map to green */
>>>>> + { 36, 46 }, /* B: light cyan, map to cyan */
>>>>> + { 31, 41 }, /* C: light red, map to red */
>>>>> + { 35, 45 }, /* D: light magenta, map to magenta */
>>>>> + { 33, 43 }, /* E: yellow */
>>>>> + { 37, 47 }, /* F: white */
>>>>> +};
>>>>> +
>>>
>>> I'm not totally convinced about mapping extra colors that UEFI defines
>>> to bold.. unless you have some example of prior-art for this on other
>>> platforms.
>>
>> See
>> Standard ECMA-48 - Control Functions for Coded Character Sets
>> chapter 8.3.117 SGR - SELECT GRAPHIC RENDITION
>>
>> 1 - bold or increased intensity
>> 22 - normal colour or normal intensity (neither bold nor faint)
>>
>> You can easily experiment in your bash shell like this:
>>
>> printf "\x1b[1;32;40m bold \x1b[22;32;40m normal\x1b[22;39;49m\n";
>>
>> You will find that "bold" prints bold and bright in the KDE konsole and
>> xterm.
>
> but I think we don't want (potential) font changes, just color changes..
>
> if you can find the code in edk2 that does this, I guess it would be a
> reasonable precedent to follow.. but if not I wanted to avoid things
> that might be specific to particular terminal emulators, since I
> wasn't really looking forward to testing them all. Otherwise I'd just
> rely on the extension that allowed 256 colors..
>
> BR,
> -R
The same problem seems has led the EDK folks to a similar solution.
See
MdeModulePkg/Universal/Console/TerminalDxe/TerminalConOut.c
Everything starts with this array:
{ ESC, '[', '0', 'm', ESC, '[', '4', '0', 'm', ESC, '[', '4', '0', 'm', 0 };
The first '0' is replaced by either 0 or 1 depending on brightness.
mSetAttributeString[BRIGHT_CONTROL_OFFSET] =
(CHAR16) ('0' + BrightControl);
The first '4', '0' is replaced by the foreground color.
The second '4', '0' is replaced by the background color.
ECMA 48 says:
0 - default rendition, cancels the effect of any preceding SGR
So you can use this instead of 22.
Best regards
Heinrich
>
>> Using colors 90-97 as foreground colors produces only bright but not
>> bold in the KDE konsole and xterm:
>>
>> printf "\x1b[92;40m bold \x1b[32;40m normal\x1b[22;39;49m\n";
>>
>> But these codes are not defined in ECMA-48.
>>
>> Best regards
>>
>> Heinrich
>>
>
^ permalink raw reply
* Re: [PATCH net-next 4/4] selinux: bpf: Add addtional check for bpf object file receive
From: Daniel Borkmann @ 2017-10-04 23:52 UTC (permalink / raw)
To: Chenbo Feng, netdev, SELinux, linux-security-module
Cc: Jeffrey Vander Stoep, Lorenzo Colitti, Alexei Starovoitov,
Chenbo Feng
In-Reply-To: <59D57263.3080601@iogearbox.net>
On 10/05/2017 01:44 AM, Daniel Borkmann wrote:
> On 10/04/2017 08:29 PM, 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.
>
> [...]
>> +/* 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.
>> + */
> [...]
>
> If selinux/lsm folks have some input on this one in particular, would
> be great. The issue is not really tied to bpf specifically, but to the
> use of anon-inodes wrt fd passing. Maybe some generic resolution can
> be found to tackle this ...
Perhaps even just a generic callback in struct file_operations might be
better in order to just retrieve the secctx from the underlying object
in case of anon-inodes and then have a generic check in selinux_file_receive()
for the case when such callback is set, such that we don't need to put
specific bpf logic there.
^ permalink raw reply
* [PATCH net-next 4/4] selinux: bpf: Add addtional check for bpf object file receive
From: Daniel Borkmann @ 2017-10-04 23:52 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <59D57263.3080601@iogearbox.net>
On 10/05/2017 01:44 AM, Daniel Borkmann wrote:
> On 10/04/2017 08:29 PM, 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.
>
> [...]
>> +/* 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.
>> + */
> [...]
>
> If selinux/lsm folks have some input on this one in particular, would
> be great. The issue is not really tied to bpf specifically, but to the
> use of anon-inodes wrt fd passing. Maybe some generic resolution can
> be found to tackle this ...
Perhaps even just a generic callback in struct file_operations might be
better in order to just retrieve the secctx from the underlying object
in case of anon-inodes and then have a generic check in selinux_file_receive()
for the case when such callback is set, such that we don't need to put
specific bpf logic there.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options
From: Linus Torvalds @ 2017-10-04 23:52 UTC (permalink / raw)
To: Roberts, William C, Tejun Heo
Cc: Jordan Glover, Tobin C. Harding, Greg KH, Petr Mladek,
Joe Perches, Ian Campbell, Sergey Senozhatsky,
kernel-hardening@lists.openwall.com, Catalin Marinas, Will Deacon,
Steven Rostedt, Chris Fries, Dave Weinstein
In-Reply-To: <476DC76E7D1DF2438D32BFADF679FC563EAF4F29@ORSMSX103.amr.corp.intel.com>
On Wed, Oct 4, 2017 at 2:58 PM, Roberts, William C
<william.c.roberts@intel.com> wrote:
>
> I agree with you 100% kptr restrict is odd, and I don't think anyone should have had to opt in to be
> cleansed via kptr_restrict value via %pK. Opt-in never works. One nice thing now, is that checkpatch
> has checking of %p usages and warns.
Yeah, the checkpatch thing may help for future patches.
> As far as broken things, I can't comment on desktop systems where I think it's harder to make that claim.
> I see value in embedded systems where I am shipping the whole image, So I know when/what will
> break.
>
> If this was in-tree, Android would be setting this to 4 immediately FWIW.
Does android set it to 2 right now?
But even if it does, my point is that we've had this thing for 6+
years, and it really hasn't helped fix our code much at all.
In fact, I think the opposite is true. I think it *hurts*. It hurts
exactly because it's a hack, and it makes people not bother to fix the
real problems.
I think we'd be better off just fixing code.
One thing you can do today is just look through your 'dmesg' for what
looks like kernel addresses (if virtual addresses is what you're
interested in - obviously physical addresses will look different). On
x86-64, for example, something like this:
dmesg | egrep 'ffff[0-9a-f]{12}'
might be interesting to look at. It shows (for me) that we show the
percpu address mapping, for example. That certainly sounds interesting
to a potential attacker, and I suspect Tejun isn't really interested
in that information any more. Added to Cc.
It also shows
software IO TLB [mem PA-PB] (64MB) mapped at [VA-VB]
for example. And THIS IS IMPORTANT! The physical address is shown
with "%#010llx".
See what I'm saying? The kptr_restrict games are just that: games and
security theater. If you actually care about things like physical
addresses, you don't say "let's hide %pa". Because that's not how the
real world works. I found one case that would entirely have missed
with the very first trivial grep I did.
So I'm claiming that anybody who says "it's too hard to fix it for
real, let's just paper over it in vsprintf.c" is fundamentally going
to miss things like this. I agree that it might be painful to try to
figure out where the problems are, but somebody like google probably
has a lot of dmesg output, and it should not be that hard to do the
above kinds of "let's just see what leaks, and FIX it".
Linus
^ permalink raw reply
* [PATCH] scsi: qla2xxx: remove dead code in qla82xx_write_flash_data
From: Gustavo A. R. Silva @ 2017-10-04 23:28 UTC (permalink / raw)
To: qla2xxx-upstream, James E.J. Bottomley, Martin K. Petersen
Cc: linux-scsi, linux-kernel, Gustavo A. R. Silva
Local variable page_mode is assigned to a constant value and it is never
updated again. Remove this variable and the dead code it guards.
Addresses-Coverity-ID: 200420
Addresses-Coverity-ID: 114338
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
This code was tested by compilation only. Also, notice that this code has
not been updated since 2010.
drivers/scsi/qla2xxx/qla_nx.c | 54 ++-----------------------------------------
1 file changed, 2 insertions(+), 52 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_nx.c b/drivers/scsi/qla2xxx/qla_nx.c
index a77c339..d5c3d36 100644
--- a/drivers/scsi/qla2xxx/qla_nx.c
+++ b/drivers/scsi/qla2xxx/qla_nx.c
@@ -2676,33 +2676,14 @@ qla82xx_write_flash_data(struct scsi_qla_host *vha, uint32_t *dwptr,
int ret;
uint32_t liter;
uint32_t rest_addr;
- dma_addr_t optrom_dma;
- void *optrom = NULL;
- int page_mode = 0;
struct qla_hw_data *ha = vha->hw;
- ret = -1;
-
- /* Prepare burst-capable write on supported ISPs. */
- if (page_mode && !(faddr & 0xfff) &&
- dwords > OPTROM_BURST_DWORDS) {
- optrom = dma_alloc_coherent(&ha->pdev->dev, OPTROM_BURST_SIZE,
- &optrom_dma, GFP_KERNEL);
- if (!optrom) {
- ql_log(ql_log_warn, vha, 0xb01b,
- "Unable to allocate memory "
- "for optrom burst write (%x KB).\n",
- OPTROM_BURST_SIZE / 1024);
- }
- }
-
rest_addr = ha->fdt_block_size - 1;
-
ret = qla82xx_unprotect_flash(ha);
if (ret) {
ql_log(ql_log_warn, vha, 0xb01c,
"Unable to unprotect flash for update.\n");
- goto write_done;
+ return ret;
}
for (liter = 0; liter < dwords; liter++, faddr += 4, dwptr++) {
@@ -2718,34 +2699,6 @@ qla82xx_write_flash_data(struct scsi_qla_host *vha, uint32_t *dwptr,
}
}
- /* Go with burst-write. */
- if (optrom && (liter + OPTROM_BURST_DWORDS) <= dwords) {
- /* Copy data to DMA'ble buffer. */
- memcpy(optrom, dwptr, OPTROM_BURST_SIZE);
-
- ret = qla2x00_load_ram(vha, optrom_dma,
- (ha->flash_data_off | faddr),
- OPTROM_BURST_DWORDS);
- if (ret != QLA_SUCCESS) {
- ql_log(ql_log_warn, vha, 0xb01e,
- "Unable to burst-write optrom segment "
- "(%x/%x/%llx).\n", ret,
- (ha->flash_data_off | faddr),
- (unsigned long long)optrom_dma);
- ql_log(ql_log_warn, vha, 0xb01f,
- "Reverting to slow-write.\n");
-
- dma_free_coherent(&ha->pdev->dev,
- OPTROM_BURST_SIZE, optrom, optrom_dma);
- optrom = NULL;
- } else {
- liter += OPTROM_BURST_DWORDS - 1;
- faddr += OPTROM_BURST_DWORDS - 1;
- dwptr += OPTROM_BURST_DWORDS - 1;
- continue;
- }
- }
-
ret = qla82xx_write_flash_dword(ha, faddr,
cpu_to_le32(*dwptr));
if (ret) {
@@ -2760,10 +2713,7 @@ qla82xx_write_flash_data(struct scsi_qla_host *vha, uint32_t *dwptr,
if (ret)
ql_log(ql_log_warn, vha, 0xb021,
"Unable to protect flash after update.\n");
-write_done:
- if (optrom)
- dma_free_coherent(&ha->pdev->dev,
- OPTROM_BURST_SIZE, optrom, optrom_dma);
+
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v7 2/5] x86/cpuid: Add generic table for cpuid dependencies
From: Andi Kleen @ 2017-10-04 23:49 UTC (permalink / raw)
To: x86; +Cc: hpa, linux-kernel, Andi Kleen, Jonathan McDowell
In-Reply-To: <20171004234930.5685-1-andi@firstfloor.org>
From: Andi Kleen <ak@linux.intel.com>
Some CPUID features depend on other features. Currently it's
possible to to clear dependent features, but not clear the base features,
which can cause various interesting problems.
This patch implements a generic table to describe dependencies
between CPUID features, to be used by all code that clears
CPUID.
Some subsystems (like XSAVE) had an own implementation of this,
but it's better to do it all in a single place for everyone.
Then clear_cpu_cap and setup_clear_cpu_cap always look up
this table and clear all dependencies too.
This is intended to be a practical table: only for features
that make sense to clear. If someone for example clears FPU,
or other features that are essentially part of the required
base feature set, not much is going to work. Handling
that is right now out of scope. We're only handling
features which can be usefully cleared.
v2: Add EXPORT_SYMBOL for clear_cpu_id for lguest
v3:
Fix handling of depending issues
Fix dups in the table (Jonathan McDowell)
Cc: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
arch/x86/include/asm/cpufeature.h | 8 +++-
arch/x86/include/asm/cpufeatures.h | 5 ++
arch/x86/kernel/cpu/Makefile | 1 +
arch/x86/kernel/cpu/cpuid-deps.c | 94 ++++++++++++++++++++++++++++++++++++++
4 files changed, 106 insertions(+), 2 deletions(-)
create mode 100644 arch/x86/kernel/cpu/cpuid-deps.c
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index d59c15c3defd..e6145f383ff8 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -125,8 +125,12 @@ extern const char * const x86_bug_flags[NBUGINTS*32];
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
#define set_cpu_cap(c, bit) set_bit(bit, (unsigned long *)((c)->x86_capability))
-#define clear_cpu_cap(c, bit) clear_bit(bit, (unsigned long *)((c)->x86_capability))
-#define setup_clear_cpu_cap(bit) do { \
+#define __clear_cpu_cap(c, bit) clear_bit(bit, (unsigned long *)((c)->x86_capability))
+
+extern void setup_clear_cpu_cap(int bit);
+extern void clear_cpu_cap(struct cpuinfo_x86 *cpu, int bit);
+
+#define __setup_clear_cpu_cap(bit) do { \
clear_cpu_cap(&boot_cpu_data, bit); \
set_bit(bit, (unsigned long *)cpu_caps_cleared); \
} while (0)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 2519c6c801c9..401a70992060 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -21,6 +21,11 @@
* this feature bit is not displayed in /proc/cpuinfo at all.
*/
+/*
+ * When adding new features here that depend on other features,
+ * please update the table in kernel/cpu/cpuid-deps.c
+ */
+
/* Intel-defined CPU features, CPUID level 0x00000001 (edx), word 0 */
#define X86_FEATURE_FPU ( 0*32+ 0) /* Onboard FPU */
#define X86_FEATURE_VME ( 0*32+ 1) /* Virtual Mode Extensions */
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index e17942c131c8..de260fae1017 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -22,6 +22,7 @@ obj-y += rdrand.o
obj-y += match.o
obj-y += bugs.o
obj-$(CONFIG_CPU_FREQ) += aperfmperf.o
+obj-y += cpuid-deps.o
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
new file mode 100644
index 000000000000..f3087d46459d
--- /dev/null
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -0,0 +1,94 @@
+/* Declare dependencies between CPUIDs */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <asm/cpufeature.h>
+
+struct cpuid_dep {
+ int feature;
+ int disable;
+};
+
+/*
+ * Table of CPUID features that depend on others.
+ *
+ * This only includes dependencies that can be usefully disabled, not
+ * features part of the base set (like FPU).
+ */
+const static struct cpuid_dep cpuid_deps[] = {
+ { X86_FEATURE_XSAVE, X86_FEATURE_XSAVEOPT },
+ { X86_FEATURE_XSAVE, X86_FEATURE_XSAVEC },
+ { X86_FEATURE_XSAVE, X86_FEATURE_XSAVES },
+ { X86_FEATURE_XSAVE, X86_FEATURE_AVX },
+ { X86_FEATURE_XSAVE, X86_FEATURE_AVX512F },
+ { X86_FEATURE_XSAVE, X86_FEATURE_PKU },
+ { X86_FEATURE_XSAVE, X86_FEATURE_MPX },
+ { X86_FEATURE_XSAVE, X86_FEATURE_XGETBV1 },
+ { X86_FEATURE_XMM, X86_FEATURE_XMM2 },
+ { X86_FEATURE_XMM2, X86_FEATURE_XMM3 },
+ { X86_FEATURE_XMM2, X86_FEATURE_XMM4_1 },
+ { X86_FEATURE_XMM2, X86_FEATURE_XMM4_2 },
+ { X86_FEATURE_XMM2, X86_FEATURE_XMM3 },
+ { X86_FEATURE_XMM2, X86_FEATURE_PCLMULQDQ },
+ { X86_FEATURE_XMM2, X86_FEATURE_SSSE3 },
+ { X86_FEATURE_XMM2, X86_FEATURE_F16C },
+ { X86_FEATURE_XMM2, X86_FEATURE_AES },
+ { X86_FEATURE_FMA, X86_FEATURE_AVX },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512IFMA },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512PF },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512ER },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512CD },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512DQ },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512BW },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512VL },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512VBMI },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512_4VNNIW },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512_4FMAPS },
+ { X86_FEATURE_AVX512F, X86_FEATURE_AVX512_VPOPCNTDQ },
+ { X86_FEATURE_AVX, X86_FEATURE_AVX2 },
+ {}
+};
+
+static inline void clearfeat(struct cpuinfo_x86 *cpu, int feat)
+{
+ if (!cpu)
+ __setup_clear_cpu_cap(feat);
+ else
+ __clear_cpu_cap(cpu, feat);
+}
+
+static void do_clear_cpu_cap(struct cpuinfo_x86 *cpu, int feat)
+{
+ bool changed;
+ __u32 disable[NCAPINTS + NBUGINTS];
+ unsigned long *disable_mask = (unsigned long *)disable;
+ const struct cpuid_dep *d;
+
+ clearfeat(cpu, feat);
+
+ /* Collect all features to disable, handling dependencies */
+ memset(disable, 0, sizeof(disable));
+ __set_bit(feat, disable_mask);
+ do {
+ changed = false;
+ for (d = cpuid_deps; d->feature; d++) {
+ if (test_bit(d->feature, disable_mask) &&
+ !__test_and_set_bit(d->disable, disable_mask)) {
+ changed = true;
+ clearfeat(cpu, d->disable);
+ }
+ }
+ } while (changed);
+}
+
+void clear_cpu_cap(struct cpuinfo_x86 *cpu, int feat)
+{
+ do_clear_cpu_cap(cpu, feat);
+}
+
+EXPORT_SYMBOL_GPL(clear_cpu_cap);
+
+void setup_clear_cpu_cap(int feat)
+{
+ do_clear_cpu_cap(NULL, feat);
+}
--
2.13.6
^ permalink raw reply related
* [PATCH v7 5/5] x86/xsave: Using generic CPUID clearing when disabling XSAVE
From: Andi Kleen @ 2017-10-04 23:49 UTC (permalink / raw)
To: x86; +Cc: hpa, linux-kernel, Andi Kleen
In-Reply-To: <20171004234930.5685-1-andi@firstfloor.org>
From: Andi Kleen <ak@linux.intel.com>
Now that the generic CPUID clearing understands dependencies,
it's enough to clear the XSAVE CPUID bit to clear all depending
features when XSAVE gets disabled.
So we don't need this hard to maintain explicit list
of features depending on XSAVE anymore. Just call the generic
clear_cpu_cap() function for XSAVE.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
arch/x86/kernel/fpu/xstate.c | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 2a46efe0b9a9..1e2d7b7fb96f 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -73,26 +73,6 @@ unsigned int fpu_user_xstate_size;
void fpu__xstate_clear_all_cpu_caps(void)
{
setup_clear_cpu_cap(X86_FEATURE_XSAVE);
- setup_clear_cpu_cap(X86_FEATURE_XSAVEOPT);
- setup_clear_cpu_cap(X86_FEATURE_XSAVEC);
- setup_clear_cpu_cap(X86_FEATURE_XSAVES);
- setup_clear_cpu_cap(X86_FEATURE_AVX);
- setup_clear_cpu_cap(X86_FEATURE_AVX2);
- setup_clear_cpu_cap(X86_FEATURE_AVX512F);
- setup_clear_cpu_cap(X86_FEATURE_AVX512IFMA);
- setup_clear_cpu_cap(X86_FEATURE_AVX512PF);
- setup_clear_cpu_cap(X86_FEATURE_AVX512ER);
- setup_clear_cpu_cap(X86_FEATURE_AVX512CD);
- setup_clear_cpu_cap(X86_FEATURE_AVX512DQ);
- setup_clear_cpu_cap(X86_FEATURE_AVX512BW);
- setup_clear_cpu_cap(X86_FEATURE_AVX512VL);
- setup_clear_cpu_cap(X86_FEATURE_MPX);
- setup_clear_cpu_cap(X86_FEATURE_XGETBV1);
- setup_clear_cpu_cap(X86_FEATURE_AVX512VBMI);
- setup_clear_cpu_cap(X86_FEATURE_PKU);
- setup_clear_cpu_cap(X86_FEATURE_AVX512_4VNNIW);
- setup_clear_cpu_cap(X86_FEATURE_AVX512_4FMAPS);
- setup_clear_cpu_cap(X86_FEATURE_AVX512_VPOPCNTDQ);
}
/*
--
2.13.6
^ permalink raw reply related
* [PATCH v7 1/5] x86/xsave: Move xsave initialization to after parsing early parameters
From: Andi Kleen @ 2017-10-04 23:49 UTC (permalink / raw)
To: x86; +Cc: hpa, linux-kernel, Andi Kleen
In-Reply-To: <20171004234930.5685-1-andi@firstfloor.org>
From: Andi Kleen <ak@linux.intel.com>
Move the XSAVE initialization code to be after parsing early parameters.
I don't see any reason why the FPU code needs to be initialized that
early, nothing else in the initialization phase uses XSAVE.
This is useful to be able to handle command line parameters in the
XSAVE initialization code.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
arch/x86/kernel/cpu/common.c | 2 --
arch/x86/kernel/setup.c | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c9176bae7fd8..fd47692e5ce9 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -903,8 +903,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
}
setup_force_cpu_cap(X86_FEATURE_ALWAYS);
- fpu__init_system(c);
-
#ifdef CONFIG_X86_32
/*
* Regardless of whether PCID is enumerated, the SDM says
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 0957dd73d127..2260e586295f 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -92,6 +92,7 @@
#include <asm/processor.h>
#include <asm/bugs.h>
#include <asm/kasan.h>
+#include <asm/fpu/internal.h>
#include <asm/vsyscall.h>
#include <asm/cpu.h>
@@ -992,6 +993,8 @@ void __init setup_arch(char **cmdline_p)
parse_early_param();
+ fpu__init_system(&boot_cpu_data);
+
#ifdef CONFIG_MEMORY_HOTPLUG
/*
* Memory used by the kernel cannot be hot-removed because Linux
--
2.13.6
^ permalink raw reply related
* [PATCH v7 3/5] x86/cpuid: Make clearcpuid an early param
From: Andi Kleen @ 2017-10-04 23:49 UTC (permalink / raw)
To: x86; +Cc: hpa, linux-kernel, Andi Kleen
In-Reply-To: <20171004234930.5685-1-andi@firstfloor.org>
From: Andi Kleen <ak@linux.intel.com>
Make clearcpuid= an early param, to make sure it is parsed
before the XSAVE initialization. This allows to modify
XSAVE state by clearing specific CPUID bits.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
arch/x86/kernel/cpu/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index fd47692e5ce9..ff51c61d2df0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1310,7 +1310,7 @@ static __init int setup_disablecpuid(char *arg)
return 1;
}
-__setup("clearcpuid=", setup_disablecpuid);
+early_param("clearcpuid", setup_disablecpuid);
#ifdef CONFIG_X86_64
DEFINE_PER_CPU_FIRST(union irq_stack_union,
--
2.13.6
^ permalink raw reply related
* [PATCH v7 4/5] x86/xsave: Make XSAVE check the base CPUID features before enabling
From: Andi Kleen @ 2017-10-04 23:49 UTC (permalink / raw)
To: x86; +Cc: hpa, linux-kernel, Andi Kleen
In-Reply-To: <20171004234930.5685-1-andi@firstfloor.org>
From: Andi Kleen <ak@linux.intel.com>
Before enabling XSAVE, not only check the XSAVE specific CPUID bits,
but also the base CPUID features of the respective XSAVE feature.
This allows to disable individual XSAVE states using the existing
clearcpuid= option, which can be useful for performance testing
and debugging, and also in general avoids inconsistencies.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
arch/x86/kernel/fpu/xstate.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index f1d5476c9022..2a46efe0b9a9 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -15,6 +15,7 @@
#include <asm/fpu/xstate.h>
#include <asm/tlbflush.h>
+#include <asm/cpufeature.h>
/*
* Although we spell it out in here, the Processor Trace
@@ -36,6 +37,19 @@ static const char *xfeature_names[] =
"unknown xstate feature" ,
};
+static short xsave_cpuid_features[] = {
+ X86_FEATURE_FPU,
+ X86_FEATURE_XMM,
+ X86_FEATURE_AVX,
+ X86_FEATURE_MPX,
+ X86_FEATURE_MPX,
+ X86_FEATURE_AVX512F,
+ X86_FEATURE_AVX512F,
+ X86_FEATURE_AVX512F,
+ X86_FEATURE_INTEL_PT,
+ X86_FEATURE_PKU,
+};
+
/*
* Mask of xstate features supported by the CPU and the kernel:
*/
@@ -726,6 +740,7 @@ void __init fpu__init_system_xstate(void)
unsigned int eax, ebx, ecx, edx;
static int on_boot_cpu __initdata = 1;
int err;
+ int i;
WARN_ON_FPU(!on_boot_cpu);
on_boot_cpu = 0;
@@ -759,6 +774,13 @@ void __init fpu__init_system_xstate(void)
goto out_disable;
}
+ /*
+ * Clear XSAVE features that are disabled in the normal CPUID.
+ */
+ for (i = 0; i < ARRAY_SIZE(xsave_cpuid_features); i++)
+ if (!boot_cpu_has(xsave_cpuid_features[i]))
+ xfeatures_mask &= ~BIT(i);
+
xfeatures_mask &= fpu__get_supported_xfeatures_mask();
/* Enable xstate instructions to be able to continue with initialization: */
--
2.13.6
^ permalink raw reply related
* Support generic disabling of all XSAVE features
From: Andi Kleen @ 2017-10-04 23:49 UTC (permalink / raw)
To: x86; +Cc: hpa, linux-kernel
For performance testing and debugging it can be useful to disable XSAVE
features individually.
This patchkit hooks up XSAVE with the generic clearcpuid=... option,
so that disabling a CPUID feature automatically disables the respective
XSAVE feature.
It also cleans up CPUID dependency management. Currently it's
possible to generate configurations with cleacpuid that crash.
It replaces an earlier patchkit that did this with special
case options.
v1:
Initial post
v2:
Work around broken lguest by exporting set_cpu_cap
Repost with cover letter
v3:
Repost. No changes to code.
v4:
Rebase to latest tree. Repost.
v5:
Fix dependency algorithm. Clean dups in table. Rebase.
v6:
Rebase. No changes to code.
v7:
Rebase. No changes to code.
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: Rename SBC to DragonBoard 410c
From: Rob Clark @ 2017-10-04 23:49 UTC (permalink / raw)
To: Stephen Boyd
Cc: Nicolas Dechesne, Srinivas Kandagatla, Linus Walleij,
linux-arm-kernel@lists.infradead.org, linux-arm-msm, Andy Gross,
David Brown, Bjorn Andersson, linux-soc, Alexander Graf,
Peter Robinson
In-Reply-To: <20171004232125.GC457@codeaurora.org>
On Wed, Oct 4, 2017 at 7:21 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/04, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 6:09 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> > On 10/04, Rob Clark wrote:
>> >> If we managed to get this in before the 4.14 LTS I might feel
>> >> differently. But afterwards, totally not. :-(
>> >>
>> >
>> > How do you install dtbs onto your device? Should be simple enough
>> > to run 'mv' on the new filename to the old one?
>> >
>>
>> it is part of the kernel package
>
> Are you copying the file out of the arch/arm64/boot/dts
> directory? Or you're using dtbs_install rule?
dtbs_install
>> but fixing it in the distro means fixing it in *every* distro..
>
> That assumes every distro has a bootloader that's looking for one
> file name vs. the other. And that the distro hasn't updated the
> bootloader to pick a different name.
well, the distro starts at grub.. u-boot (implementing the uefi
interface, and loading the dtb) is part of the board's "bios".. we
kinda want to avoid having to provide different versions of "bios" for
users to flash depending on kernel version
>>
>> if we are going for a workaround, then it should be the kernel
>> installing a symlink. Not every distro having to fix things up in the
>> same way for one particular board.
>
> There was a discussion about this years ago when the dtbs_install
> rule was introduced to the kernel makefiles[1]. Maybe the
> sentiment has changed, but it seems that people involved in that
> thread didn't consider the filename an ABI. Also, take a look at
> commit f4d4ffc03efc ("kbuild: dtbs_install: new make target")
> where it says:
>
> "Removed option to call external script. Copying the files should
> be sufficient and a build system can post-process the install
> directory. Despite the fact an external script is used for
> installing the kernel, I don't think that is a pattern that
> should be encouraged. I would rather see buildroot type tools
> post process the install directory to rename or move dtb files
> after installing to a staging directory."
So there is kernel-install (which regen's initrd and runs
/lib/kernel/install.d/* scripts).. but so far afaik it hasn't had to
do board specific fixups.. and since this is a change there would have
to propagate into every distro, I'd prefer either not needing to do
this in the first place, or doing it in dtbs_install..
Then again, for db410c, since prior to 4.14 we didn't have an iommu
driver (which display and gpu needed to work without hacks, and
therefore less interesting for distro users), if we manage to sneak
this change into 4.14, then I guess we could live with the short term
headache of telling distro users to flash a different "bios" depending
on kernel version.
After that, we *really* don't want the headache of handholding users
thru bios upgrade for 4.14-lts to newer kernel upgrade.
BR,
-R
> which makes it look like the distro installation scripts would
> rename things if desired.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/210562.html
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: Rename SBC to DragonBoard 410c
From: Rob Clark @ 2017-10-04 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171004232125.GC457@codeaurora.org>
On Wed, Oct 4, 2017 at 7:21 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/04, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 6:09 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> > On 10/04, Rob Clark wrote:
>> >> If we managed to get this in before the 4.14 LTS I might feel
>> >> differently. But afterwards, totally not. :-(
>> >>
>> >
>> > How do you install dtbs onto your device? Should be simple enough
>> > to run 'mv' on the new filename to the old one?
>> >
>>
>> it is part of the kernel package
>
> Are you copying the file out of the arch/arm64/boot/dts
> directory? Or you're using dtbs_install rule?
dtbs_install
>> but fixing it in the distro means fixing it in *every* distro..
>
> That assumes every distro has a bootloader that's looking for one
> file name vs. the other. And that the distro hasn't updated the
> bootloader to pick a different name.
well, the distro starts at grub.. u-boot (implementing the uefi
interface, and loading the dtb) is part of the board's "bios".. we
kinda want to avoid having to provide different versions of "bios" for
users to flash depending on kernel version
>>
>> if we are going for a workaround, then it should be the kernel
>> installing a symlink. Not every distro having to fix things up in the
>> same way for one particular board.
>
> There was a discussion about this years ago when the dtbs_install
> rule was introduced to the kernel makefiles[1]. Maybe the
> sentiment has changed, but it seems that people involved in that
> thread didn't consider the filename an ABI. Also, take a look at
> commit f4d4ffc03efc ("kbuild: dtbs_install: new make target")
> where it says:
>
> "Removed option to call external script. Copying the files should
> be sufficient and a build system can post-process the install
> directory. Despite the fact an external script is used for
> installing the kernel, I don't think that is a pattern that
> should be encouraged. I would rather see buildroot type tools
> post process the install directory to rename or move dtb files
> after installing to a staging directory."
So there is kernel-install (which regen's initrd and runs
/lib/kernel/install.d/* scripts).. but so far afaik it hasn't had to
do board specific fixups.. and since this is a change there would have
to propagate into every distro, I'd prefer either not needing to do
this in the first place, or doing it in dtbs_install..
Then again, for db410c, since prior to 4.14 we didn't have an iommu
driver (which display and gpu needed to work without hacks, and
therefore less interesting for distro users), if we manage to sneak
this change into 4.14, then I guess we could live with the short term
headache of telling distro users to flash a different "bios" depending
on kernel version.
After that, we *really* don't want the headache of handholding users
thru bios upgrade for 4.14-lts to newer kernel upgrade.
BR,
-R
> which makes it look like the distro installation scripts would
> rename things if desired.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/210562.html
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [Intel-wired-lan] [PATCH 13/13 net-next] i40e: convert i40e_set_link_ksettings to new API
From: Shannon Nelson @ 2017-10-04 23:47 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20171004175839.28364-14-alan.brady@intel.com>
On 10/4/2017 10:58 AM, Alan Brady wrote:
> This finishes off the conversion to the new ethtool API by removing the
> old macros being used in i40e_set_link_ksettings and replacing them with
> shiny new ones.
>
> This conversion also allows us to provide link speed support for new 25G
> and 10G macros which is included here as well.
>
> Signed-off-by: Alan Brady <alan.brady@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 94 ++++++++++++++++----------
> 1 file changed, 58 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> index f25cdd4cb860..489aecd3f5dc 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> @@ -855,9 +855,7 @@ static int i40e_set_link_ksettings(struct net_device *netdev,
> i40e_status status = 0;
> int timeout = 50;
> int err = 0;
> - u32 autoneg;
> - u32 advertise;
> - u32 tmp;
> + u8 autoneg;
>
> /* Changing port settings is not supported if this isn't the
> * port's controlling PF
> @@ -885,28 +883,35 @@ static int i40e_set_link_ksettings(struct net_device *netdev,
> /* copy the ksettings to copy_ks to avoid modifying the origin */
> memcpy(©_ks, ks, sizeof(struct ethtool_link_ksettings));
>
> + /* save autoneg out of ksettings */
> + autoneg = copy_ks.base.autoneg;
> +
> + memset(&safe_ks, 0, sizeof(safe_ks));
> + /* Get link modes supported by hardware... */
> + i40e_phy_type_to_ethtool(pf, &safe_ks);
> + /* ...and check against modes requested by user.
> + * Return an error if unsupported mode was set.
> + */
Please don't split this comment, it makes things harder to read.
sln
> + if (!bitmap_subset(copy_ks.link_modes.advertising,
> + safe_ks.link_modes.supported,
> + __ETHTOOL_LINK_MODE_MASK_NBITS))
> + return -EINVAL;
> +
> /* get our own copy of the bits to check against */
> memset(&safe_ks, 0, sizeof(struct ethtool_link_ksettings));
> + safe_ks.base.cmd = copy_ks.base.cmd;
> + safe_ks.base.link_mode_masks_nwords =
> + copy_ks.base.link_mode_masks_nwords;
> i40e_get_link_ksettings(netdev, &safe_ks);
>
> - /* save autoneg and speed out of ksettings */
> - autoneg = ks->base.autoneg;
> - ethtool_convert_link_mode_to_legacy_u32(&advertise,
> - ks->link_modes.advertising);
> -
> - /* set autoneg and speed back to what they currently are */
> + /* set autoneg back to what it currently is */
> copy_ks.base.autoneg = safe_ks.base.autoneg;
> - ethtool_convert_link_mode_to_legacy_u32(
> - &tmp, safe_ks.link_modes.advertising);
> - ethtool_convert_legacy_u32_to_link_mode(
> - copy_ks.link_modes.advertising, tmp);
>
> - copy_ks.base.cmd = safe_ks.base.cmd;
> -
> - /* If copy_ks and safe_ks are not the same now, then they are
> - * trying to set something that we do not support
> + /* If copy_ks.base and safe_ks.base are not the same now, then they are
> + * trying to set something that we do not support.
> */
> - if (memcmp(©_ks, &safe_ks, sizeof(struct ethtool_link_ksettings)))
> + if (memcmp(©_ks.base, &safe_ks.base,
> + sizeof(struct ethtool_link_settings)))
> return -EOPNOTSUPP;
>
> while (test_and_set_bit(__I40E_CONFIG_BUSY, pf->state)) {
> @@ -967,28 +972,45 @@ static int i40e_set_link_ksettings(struct net_device *netdev,
> }
> }
>
> - ethtool_convert_link_mode_to_legacy_u32(&tmp,
> - safe_ks.link_modes.supported);
> - if (advertise & ~tmp) {
> - err = -EINVAL;
> - goto done;
> - }
> -
> - if (advertise & ADVERTISED_100baseT_Full)
> + if (ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 100baseT_Full))
> config.link_speed |= I40E_LINK_SPEED_100MB;
> - if (advertise & ADVERTISED_1000baseT_Full ||
> - advertise & ADVERTISED_1000baseKX_Full)
> + if (ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 1000baseT_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 1000baseX_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 1000baseKX_Full))
> config.link_speed |= I40E_LINK_SPEED_1GB;
> - if (advertise & ADVERTISED_10000baseT_Full ||
> - advertise & ADVERTISED_10000baseKX4_Full ||
> - advertise & ADVERTISED_10000baseKR_Full)
> + if (ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 10000baseT_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 10000baseKX4_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 10000baseKR_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 10000baseCR_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 10000baseSR_Full))
> config.link_speed |= I40E_LINK_SPEED_10GB;
> - if (advertise & ADVERTISED_20000baseKR2_Full)
> + if (ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 20000baseKR2_Full))
> config.link_speed |= I40E_LINK_SPEED_20GB;
> - if (advertise & ADVERTISED_40000baseKR4_Full ||
> - advertise & ADVERTISED_40000baseCR4_Full ||
> - advertise & ADVERTISED_40000baseSR4_Full ||
> - advertise & ADVERTISED_40000baseLR4_Full)
> + if (ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 25000baseCR_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 25000baseKR_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 25000baseSR_Full))
> + config.link_speed |= I40E_LINK_SPEED_25GB;
> + if (ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 40000baseKR4_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 40000baseCR4_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 40000baseSR4_Full) ||
> + ethtool_link_ksettings_test_link_mode(ks, advertising,
> + 40000baseLR4_Full))
> config.link_speed |= I40E_LINK_SPEED_40GB;
>
> /* If speed didn't get set, set it to what it currently is.
>
^ permalink raw reply
* [Intel-wired-lan] [PATCH 10/13 net-next] i40e: convert i40e_phy_type_to_ethtool to new API
From: Shannon Nelson @ 2017-10-04 23:47 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20171004175839.28364-11-alan.brady@intel.com>
On 10/4/2017 10:58 AM, Alan Brady wrote:
> We are still largely using the old ethtool API macros. This is
> problematic because eventually they will be removed and they only
> support 32 bits of PHY types.
>
> This overhauls i40e_phy_type_to_ethtool to use only the new API. Doing
> this also allows us to provide much better support for newer 25G and 10G
> PHY types which is included here as well.
>
> The remaining usages of the old ethtool API will be addressed in other
> patches in the series.
>
> Signed-off-by: Alan Brady <alan.brady@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 227 ++++++++++++++++++-------
> 1 file changed, 163 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> index 6ac5c7f232c6..76530a83eb70 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> @@ -241,6 +241,29 @@ static const struct i40e_priv_flags i40e_gl_gstrings_priv_flags[] = {
>
> #define I40E_GL_PRIV_FLAGS_STR_LEN ARRAY_SIZE(i40e_gl_gstrings_priv_flags)
>
> +#define I40E_ETHTOOL_LINK_MASK_SIZE \
> + BITS_TO_LONGS(__ETHTOOL_LINK_MODE_MASK_NBITS)
> +
> +/**
> + * i40e_intersect_link_mode_masks
> + * @dst: resulting intersection and first mask
> + * @src: mask to AND with
> + *
> + * Given two link mode masks, AND them together and save the result in dst.
> + */
> +static void i40e_intersect_link_masks(struct ethtool_link_ksettings *dst,
> + struct ethtool_link_ksettings *src)
> +{
> + int idx = 0;
> +
> + for (; idx < I40E_ETHTOOL_LINK_MASK_SIZE; idx++) {
> + dst->link_modes.supported[idx] &=
> + src->link_modes.supported[idx];
> + dst->link_modes.advertising[idx] &=
> + src->link_modes.advertising[idx];
> + }
> +}
> +
This might be a handy function for more than just i40e - maybe add a
size parameter and push this up to net/core/ethtool.c?
sln
> /**
> * i40e_partition_setting_complaint - generic complaint for MFP restriction
> * @pf: the PF struct
> @@ -254,95 +277,180 @@ static void i40e_partition_setting_complaint(struct i40e_pf *pf)
> /**
> * i40e_phy_type_to_ethtool - convert the phy_types to ethtool link modes
> * @pf: PF struct with phy_types
> - * @supported: pointer to the ethtool supported variable to fill in
> - * @advertising: pointer to the ethtool advertising variable to fill in
> + * @ks: ethtool link ksettings struct to fill out
> *
> **/
> -static void i40e_phy_type_to_ethtool(struct i40e_pf *pf, u32 *supported,
> - u32 *advertising)
> +static void i40e_phy_type_to_ethtool(struct i40e_pf *pf,
> + struct ethtool_link_ksettings *ks)
> {
> struct i40e_link_status *hw_link_info = &pf->hw.phy.link_info;
> u64 phy_types = pf->hw.phy.phy_types;
>
> - *supported = 0x0;
> - *advertising = 0x0;
> + ethtool_link_ksettings_zero_link_mode(ks, supported);
> + ethtool_link_ksettings_zero_link_mode(ks, advertising);
>
> if (phy_types & I40E_CAP_PHY_TYPE_SGMII) {
> - *supported |= SUPPORTED_1000baseT_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 1000baseT_Full);
> if (hw_link_info->requested_speeds & I40E_LINK_SPEED_1GB)
> - *advertising |= ADVERTISED_1000baseT_Full;
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 1000baseT_Full);
> if (pf->hw_features & I40E_HW_100M_SGMII_CAPABLE) {
> - *supported |= SUPPORTED_100baseT_Full;
> - *advertising |= ADVERTISED_100baseT_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 100baseT_Full);
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 100baseT_Full);
> }
> }
> if (phy_types & I40E_CAP_PHY_TYPE_XAUI ||
> phy_types & I40E_CAP_PHY_TYPE_XFI ||
> phy_types & I40E_CAP_PHY_TYPE_SFI ||
> phy_types & I40E_CAP_PHY_TYPE_10GBASE_SFPP_CU ||
> - phy_types & I40E_CAP_PHY_TYPE_10GBASE_AOC)
> - *supported |= SUPPORTED_10000baseT_Full;
> - if (phy_types & I40E_CAP_PHY_TYPE_10GBASE_CR1_CU ||
> - phy_types & I40E_CAP_PHY_TYPE_10GBASE_CR1 ||
> - phy_types & I40E_CAP_PHY_TYPE_10GBASE_T ||
> - phy_types & I40E_CAP_PHY_TYPE_10GBASE_SR ||
> - phy_types & I40E_CAP_PHY_TYPE_10GBASE_LR) {
> - *supported |= SUPPORTED_10000baseT_Full;
> + phy_types & I40E_CAP_PHY_TYPE_10GBASE_AOC) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 10000baseT_Full);
> + if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 10000baseT_Full);
> + }
> + if (phy_types & I40E_CAP_PHY_TYPE_10GBASE_T) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 10000baseT_Full);
> if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
> - *advertising |= ADVERTISED_10000baseT_Full;
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 10000baseT_Full);
> }
> if (phy_types & I40E_CAP_PHY_TYPE_XLAUI ||
> phy_types & I40E_CAP_PHY_TYPE_XLPPI ||
> phy_types & I40E_CAP_PHY_TYPE_40GBASE_AOC)
> - *supported |= SUPPORTED_40000baseCR4_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 40000baseCR4_Full);
> if (phy_types & I40E_CAP_PHY_TYPE_40GBASE_CR4_CU ||
> phy_types & I40E_CAP_PHY_TYPE_40GBASE_CR4) {
> - *supported |= SUPPORTED_40000baseCR4_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 40000baseCR4_Full);
> if (hw_link_info->requested_speeds & I40E_LINK_SPEED_40GB)
> - *advertising |= ADVERTISED_40000baseCR4_Full;
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 40000baseCR4_Full);
> }
> if (phy_types & I40E_CAP_PHY_TYPE_100BASE_TX) {
> - *supported |= SUPPORTED_100baseT_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 100baseT_Full);
> if (hw_link_info->requested_speeds & I40E_LINK_SPEED_100MB)
> - *advertising |= ADVERTISED_100baseT_Full;
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 100baseT_Full);
> }
> - if (phy_types & I40E_CAP_PHY_TYPE_1000BASE_T ||
> - phy_types & I40E_CAP_PHY_TYPE_1000BASE_SX ||
> - phy_types & I40E_CAP_PHY_TYPE_1000BASE_LX ||
> - phy_types & I40E_CAP_PHY_TYPE_1000BASE_T_OPTICAL) {
> - *supported |= SUPPORTED_1000baseT_Full;
> + if (phy_types & I40E_CAP_PHY_TYPE_1000BASE_T) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 1000baseT_Full);
> if (hw_link_info->requested_speeds & I40E_LINK_SPEED_1GB)
> - *advertising |= ADVERTISED_1000baseT_Full;
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 1000baseT_Full);
> }
> if (phy_types & I40E_CAP_PHY_TYPE_40GBASE_SR4)
> - *supported |= SUPPORTED_40000baseSR4_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 40000baseSR4_Full);
> if (phy_types & I40E_CAP_PHY_TYPE_40GBASE_LR4)
> - *supported |= SUPPORTED_40000baseLR4_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 40000baseLR4_Full);
> if (phy_types & I40E_CAP_PHY_TYPE_40GBASE_KR4) {
> - *supported |= SUPPORTED_40000baseKR4_Full;
> - *advertising |= ADVERTISED_40000baseKR4_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 40000baseLR4_Full);
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 40000baseLR4_Full);
> }
> if (phy_types & I40E_CAP_PHY_TYPE_20GBASE_KR2) {
> - *supported |= SUPPORTED_20000baseKR2_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 20000baseKR2_Full);
> if (hw_link_info->requested_speeds & I40E_LINK_SPEED_20GB)
> - *advertising |= ADVERTISED_20000baseKR2_Full;
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 20000baseKR2_Full);
> }
> if (phy_types & I40E_CAP_PHY_TYPE_10GBASE_KX4) {
> - *supported |= SUPPORTED_10000baseKX4_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 10000baseKX4_Full);
> if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
> - *advertising |= ADVERTISED_10000baseKX4_Full;
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 10000baseKX4_Full);
> }
> if (phy_types & I40E_CAP_PHY_TYPE_10GBASE_KR &&
> !(pf->hw_features & I40E_HW_HAVE_CRT_RETIMER)) {
> - *supported |= SUPPORTED_10000baseKR_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 10000baseKR_Full);
> if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
> - *advertising |= ADVERTISED_10000baseKR_Full;
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 10000baseKR_Full);
> }
> if (phy_types & I40E_CAP_PHY_TYPE_1000BASE_KX &&
> !(pf->hw_features & I40E_HW_HAVE_CRT_RETIMER)) {
> - *supported |= SUPPORTED_1000baseKX_Full;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 1000baseKX_Full);
> + if (hw_link_info->requested_speeds & I40E_LINK_SPEED_1GB)
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 1000baseKX_Full);
> + }
> + /* need to add 25G PHY types */
> + if (phy_types & I40E_CAP_PHY_TYPE_25GBASE_KR) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 25000baseKR_Full);
> + if (hw_link_info->requested_speeds & I40E_LINK_SPEED_25GB)
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 25000baseKR_Full);
> + }
> + if (phy_types & I40E_CAP_PHY_TYPE_25GBASE_CR) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 25000baseCR_Full);
> + if (hw_link_info->requested_speeds & I40E_LINK_SPEED_25GB)
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 25000baseCR_Full);
> + }
> + if (phy_types & I40E_CAP_PHY_TYPE_25GBASE_SR ||
> + phy_types & I40E_CAP_PHY_TYPE_25GBASE_LR) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 25000baseSR_Full);
> + if (hw_link_info->requested_speeds & I40E_LINK_SPEED_25GB)
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 25000baseSR_Full);
> + }
> + if (phy_types & I40E_CAP_PHY_TYPE_25GBASE_AOC ||
> + phy_types & I40E_CAP_PHY_TYPE_25GBASE_ACC) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 25000baseCR_Full);
> + if (hw_link_info->requested_speeds & I40E_LINK_SPEED_25GB)
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 25000baseCR_Full);
> + }
> + /* need to add new 10G PHY types */
> + if (phy_types & I40E_CAP_PHY_TYPE_10GBASE_CR1 ||
> + phy_types & I40E_CAP_PHY_TYPE_10GBASE_CR1_CU) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 10000baseCR_Full);
> + if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 10000baseCR_Full);
> + }
> + if (phy_types & I40E_CAP_PHY_TYPE_10GBASE_SR) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 10000baseSR_Full);
> + if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 10000baseSR_Full);
> + }
> + if (phy_types & I40E_CAP_PHY_TYPE_10GBASE_LR) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 10000baseLR_Full);
> + if (hw_link_info->requested_speeds & I40E_LINK_SPEED_10GB)
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 10000baseLR_Full);
> + }
> + if (phy_types & I40E_CAP_PHY_TYPE_1000BASE_SX ||
> + phy_types & I40E_CAP_PHY_TYPE_1000BASE_LX ||
> + phy_types & I40E_CAP_PHY_TYPE_1000BASE_T_OPTICAL) {
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + 1000baseX_Full);
> if (hw_link_info->requested_speeds & I40E_LINK_SPEED_1GB)
> - *advertising |= ADVERTISED_1000baseKX_Full;
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + 1000baseX_Full);
> }
> /* Autoneg PHY types */
> if (phy_types & I40E_CAP_PHY_TYPE_SGMII ||
> @@ -367,8 +475,10 @@ static void i40e_phy_type_to_ethtool(struct i40e_pf *pf, u32 *supported,
> phy_types & I40E_CAP_PHY_TYPE_1000BASE_LX ||
> phy_types & I40E_CAP_PHY_TYPE_1000BASE_KX ||
> phy_types & I40E_CAP_PHY_TYPE_100BASE_TX) {
> - *supported |= SUPPORTED_Autoneg;
> - *advertising |= ADVERTISED_Autoneg;
> + ethtool_link_ksettings_add_link_mode(ks, supported,
> + Autoneg);
> + ethtool_link_ksettings_add_link_mode(ks, advertising,
> + Autoneg);
> }
> }
>
> @@ -385,9 +495,8 @@ static void i40e_get_settings_link_up(struct i40e_hw *hw,
> struct i40e_pf *pf)
> {
> struct i40e_link_status *hw_link_info = &hw->phy.link_info;
> + struct ethtool_link_ksettings cap_ksettings;
> u32 link_speed = hw_link_info->link_speed;
> - u32 e_advertising = 0x0;
> - u32 e_supported = 0x0;
> u32 supported, advertising;
>
> ethtool_convert_link_mode_to_legacy_u32(&supported,
> @@ -519,11 +628,13 @@ static void i40e_get_settings_link_up(struct i40e_hw *hw,
> * current PHY type, get what is supported by the NVM and intersect
> * them to get what is truly supported
> */
> - i40e_phy_type_to_ethtool(pf, &e_supported,
> - &e_advertising);
> -
> - supported = supported & e_supported;
> - advertising = advertising & e_advertising;
> + ethtool_convert_legacy_u32_to_link_mode(ks->link_modes.supported,
> + supported);
> + ethtool_convert_legacy_u32_to_link_mode(ks->link_modes.advertising,
> + advertising);
> + memset(&cap_ksettings, 0, sizeof(struct ethtool_link_ksettings));
> + i40e_phy_type_to_ethtool(pf, &cap_ksettings);
> + i40e_intersect_link_masks(ks, &cap_ksettings);
>
> /* Set speed and duplex */
> switch (link_speed) {
> @@ -549,11 +660,6 @@ static void i40e_get_settings_link_up(struct i40e_hw *hw,
> break;
> }
> ks->base.duplex = DUPLEX_FULL;
> -
> - ethtool_convert_legacy_u32_to_link_mode(ks->link_modes.supported,
> - supported);
> - ethtool_convert_legacy_u32_to_link_mode(ks->link_modes.advertising,
> - advertising);
> }
>
> /**
> @@ -568,17 +674,10 @@ static void i40e_get_settings_link_down(struct i40e_hw *hw,
> struct ethtool_link_ksettings *ks,
> struct i40e_pf *pf)
> {
> - u32 supported, advertising;
> -
> /* link is down and the driver needs to fall back on
> * supported phy types to figure out what info to display
> */
> - i40e_phy_type_to_ethtool(pf, &supported, &advertising);
> -
> - ethtool_convert_legacy_u32_to_link_mode(ks->link_modes.supported,
> - supported);
> - ethtool_convert_legacy_u32_to_link_mode(ks->link_modes.advertising,
> - advertising);
> + i40e_phy_type_to_ethtool(pf, ks);
>
> /* With no link speed and duplex are unknown */
> ks->base.speed = SPEED_UNKNOWN;
>
^ permalink raw reply
* [Intel-wired-lan] [PATCH 09/13 net-next] i40e: Add new phy types for 25G AOC and ACC support.
From: Shannon Nelson @ 2017-10-04 23:47 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20171004175839.28364-10-alan.brady@intel.com>
On 10/4/2017 10:58 AM, Alan Brady wrote:
> From: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com>
>
> This patch adds support for 25G Active Optical Cables (AOC) and Active
> Copper Cables (ACC) phy types.
>
> Signed-off-by: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com>
> Signed-off-by: Krzysztof Malek <krzysztof.malek@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h | 5 +++++
> drivers/net/ethernet/intel/i40e/i40e_common.c | 2 ++
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 ++
> drivers/net/ethernet/intel/i40e/i40e_type.h | 4 ++++
> drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h | 4 ++++
> 5 files changed, 17 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
> index a8f65aed5421..ad73f6d08352 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h
> @@ -1771,10 +1771,13 @@ enum i40e_aq_phy_type {
> I40E_PHY_TYPE_25GBASE_CR = 0x20,
> I40E_PHY_TYPE_25GBASE_SR = 0x21,
> I40E_PHY_TYPE_25GBASE_LR = 0x22,
> + I40E_PHY_TYPE_25GBASE_AOC = 0x23,
> + I40E_PHY_TYPE_25GBASE_ACC = 0x24,
> I40E_PHY_TYPE_MAX,
> I40E_PHY_TYPE_NOT_SUPPORTED_HIGH_TEMP = 0xFD,
> I40E_PHY_TYPE_EMPTY = 0xFE,
> I40E_PHY_TYPE_DEFAULT = 0xFF,
> +
Unnecessary new whitespace
sln
> };
>
> #define I40E_LINK_SPEED_100MB_SHIFT 0x1
> @@ -1831,6 +1834,8 @@ struct i40e_aq_get_phy_abilities_resp {
> #define I40E_AQ_PHY_TYPE_EXT_25G_CR 0X02
> #define I40E_AQ_PHY_TYPE_EXT_25G_SR 0x04
> #define I40E_AQ_PHY_TYPE_EXT_25G_LR 0x08
> +#define I40E_AQ_PHY_TYPE_EXT_25G_AOC 0x10
> +#define I40E_AQ_PHY_TYPE_EXT_25G_ACC 0x20
> u8 fec_cfg_curr_mod_ext_info;
> #define I40E_AQ_ENABLE_FEC_KR 0x01
> #define I40E_AQ_ENABLE_FEC_RS 0x02
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c b/drivers/net/ethernet/intel/i40e/i40e_common.c
> index 53aad378d49c..1b85eb3e6443 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_common.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
> @@ -1180,6 +1180,8 @@ static enum i40e_media_type i40e_get_media_type(struct i40e_hw *hw)
> case I40E_PHY_TYPE_40GBASE_AOC:
> case I40E_PHY_TYPE_10GBASE_AOC:
> case I40E_PHY_TYPE_25GBASE_CR:
> + case I40E_PHY_TYPE_25GBASE_AOC:
> + case I40E_PHY_TYPE_25GBASE_ACC:
> media = I40E_MEDIA_TYPE_DA;
> break;
> case I40E_PHY_TYPE_1000BASE_KX:
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> index 08288b0a8cad..6ac5c7f232c6 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> @@ -502,6 +502,8 @@ static void i40e_get_settings_link_up(struct i40e_hw *hw,
> case I40E_PHY_TYPE_25GBASE_CR:
> case I40E_PHY_TYPE_25GBASE_SR:
> case I40E_PHY_TYPE_25GBASE_LR:
> + case I40E_PHY_TYPE_25GBASE_AOC:
> + case I40E_PHY_TYPE_25GBASE_ACC:
> supported = SUPPORTED_Autoneg;
> advertising = ADVERTISED_Autoneg;
> /* TODO: add speeds when ethtool is ready to support*/
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_type.h b/drivers/net/ethernet/intel/i40e/i40e_type.h
> index 0410fcbdbb94..17a99b53acd9 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_type.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
> @@ -271,6 +271,10 @@ struct i40e_phy_info {
> I40E_PHY_TYPE_OFFSET)
> #define I40E_CAP_PHY_TYPE_25GBASE_LR BIT_ULL(I40E_PHY_TYPE_25GBASE_LR + \
> I40E_PHY_TYPE_OFFSET)
> +#define I40E_CAP_PHY_TYPE_25GBASE_AOC BIT_ULL(I40E_PHY_TYPE_25GBASE_AOC + \
> + I40E_PHY_TYPE_OFFSET)
> +#define I40E_CAP_PHY_TYPE_25GBASE_ACC BIT_ULL(I40E_PHY_TYPE_25GBASE_ACC + \
> + I40E_PHY_TYPE_OFFSET)
> #define I40E_HW_CAP_MAX_GPIO 30
> /* Capabilities of a PF or a VF or the whole device */
> struct i40e_hw_capabilities {
> diff --git a/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h b/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
> index 60c892f559b9..463e331a70a9 100644
> --- a/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
> +++ b/drivers/net/ethernet/intel/i40evf/i40e_adminq_cmd.h
> @@ -1767,6 +1767,8 @@ enum i40e_aq_phy_type {
> I40E_PHY_TYPE_25GBASE_CR = 0x20,
> I40E_PHY_TYPE_25GBASE_SR = 0x21,
> I40E_PHY_TYPE_25GBASE_LR = 0x22,
> + I40E_PHY_TYPE_25GBASE_AOC = 0x23,
> + I40E_PHY_TYPE_25GBASE_ACC = 0x24,
> I40E_PHY_TYPE_MAX,
> I40E_PHY_TYPE_NOT_SUPPORTED_HIGH_TEMP = 0xFD,
> I40E_PHY_TYPE_EMPTY = 0xFE,
> @@ -1827,6 +1829,8 @@ struct i40e_aq_get_phy_abilities_resp {
> #define I40E_AQ_PHY_TYPE_EXT_25G_CR 0X02
> #define I40E_AQ_PHY_TYPE_EXT_25G_SR 0x04
> #define I40E_AQ_PHY_TYPE_EXT_25G_LR 0x08
> +#define I40E_AQ_PHY_TYPE_EXT_25G_AOC 0x10
> +#define I40E_AQ_PHY_TYPE_EXT_25G_ACC 0x20
> u8 fec_cfg_curr_mod_ext_info;
> #define I40E_AQ_ENABLE_FEC_KR 0x01
> #define I40E_AQ_ENABLE_FEC_RS 0x02
>
^ permalink raw reply
* Re: [PATCH net-next 4/4] selinux: bpf: Add addtional check for bpf object file receive
From: Daniel Borkmann @ 2017-10-04 23:44 UTC (permalink / raw)
To: Chenbo Feng, netdev, SELinux, linux-security-module
Cc: Jeffrey Vander Stoep, Lorenzo Colitti, Alexei Starovoitov,
Chenbo Feng
In-Reply-To: <20171004182932.140028-5-chenbofeng.kernel@gmail.com>
On 10/04/2017 08:29 PM, 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.
[...]
> +/* 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.
> + */
[...]
If selinux/lsm folks have some input on this one in particular, would
be great. The issue is not really tied to bpf specifically, but to the
use of anon-inodes wrt fd passing. Maybe some generic resolution can
be found to tackle this ...
^ permalink raw reply
* [PATCH net-next 4/4] selinux: bpf: Add addtional check for bpf object file receive
From: Daniel Borkmann @ 2017-10-04 23:44 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <20171004182932.140028-5-chenbofeng.kernel@gmail.com>
On 10/04/2017 08:29 PM, 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.
[...]
> +/* 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.
> + */
[...]
If selinux/lsm folks have some input on this one in particular, would
be great. The issue is not really tied to bpf specifically, but to the
use of anon-inodes wrt fd passing. Maybe some generic resolution can
be found to tackle this ...
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ACPI / LPIT: Add Low Power Idle Table (LPIT) support
From: Srinivas Pandruvada @ 2017-10-04 23:43 UTC (permalink / raw)
To: rjw; +Cc: lv.zheng, lenb, linux-acpi, linux-kernel, Srinivas Pandruvada
Added functionality to read LPIT table, which provides:
- Sysfs interface to read residency counters via
/sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
/sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
Here the count "low_power_idle_cpu_residency_us" shows the time spent
by CPU package in low power state. This is read via MSR interface, which
points to MSR for PKG C10.
Here the count "low_power_idle_system_residency_us" show the count the
system was in low power state. This is read via MMIO interface. This
is mapped to SLP_S0 residency on modern Intel systems. This residency
is achieved only when CPU is in PKG C10 and all functional blocks are
in low power state.
It is possible that none of the above counters present or anyone of the
counter present or all counters present.
For example: On my Kabylake system both of the above counters present.
After suspend to idle these counts updated and prints:
6916179
6998564
This counter can be read by tools like turbostat to display. Or it can
be used to debug, if modern systems are reaching desired low power state.
- Provides an interface to read residency counter memory address
This address can be used to get the base address of PMC memory mapped IO.
This is utilized by intel_pmc_core driver to print more debug information.
Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
Documentation/acpi/lpit.txt | 26 ++++++++
drivers/acpi/Kconfig | 5 ++
drivers/acpi/Makefile | 1 +
drivers/acpi/acpi_lpit.c | 157 ++++++++++++++++++++++++++++++++++++++++++++
drivers/acpi/scan.c | 3 +
include/acpi/acpi_lpit.h | 34 ++++++++++
6 files changed, 226 insertions(+)
create mode 100644 Documentation/acpi/lpit.txt
create mode 100644 drivers/acpi/acpi_lpit.c
create mode 100644 include/acpi/acpi_lpit.h
diff --git a/Documentation/acpi/lpit.txt b/Documentation/acpi/lpit.txt
new file mode 100644
index 0000000..6be68c0
--- /dev/null
+++ b/Documentation/acpi/lpit.txt
@@ -0,0 +1,26 @@
+To enumerate platform Low Power Idle states, Intel platforms are using
+“Low Power Idle Table” (LPIT). More details about this table can be
+downloaded from:
+http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf
+
+Residencies for each low power state can be read via FFH
+(Function fixed hardware) or a memory mapped interface.
+
+On platforms supporting S0ix sleep states, there can be two types of
+residencies:
+- CPU PKG C10 (Read via FFH interface)
+- Platform Controller Hub (PCH) SLP_S0 (Read via memory mapped interface)
+
+The following attributes are added dynamically to the cpuidle
+sysfs attribute group:
+ /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
+ /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
+
+The "low_power_idle_cpu_residency_us" attribute shows time spent
+by the CPU package in PKG C10
+
+The "low_power_idle_system_residency_us" attribute shows SLP_S0
+residency, or system time spent with the SLP_S0# signal asserted.
+This is the lowest possible system power state, achieved only when CPU is in
+PKG C10 and all functional blocks in PCH are in a low power state.
+
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f8..4bfef0f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -80,6 +80,11 @@ endif
config ACPI_SPCR_TABLE
bool
+config ACPI_LPIT
+ bool
+ depends on X86_64
+ default y
+
config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 90265ab..6a19bd7 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -56,6 +56,7 @@ acpi-$(CONFIG_DEBUG_FS) += debugfs.o
acpi-$(CONFIG_ACPI_NUMA) += numa.o
acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
acpi-y += acpi_lpat.o
+acpi-$(CONFIG_ACPI_LPIT) += acpi_lpit.o
acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
diff --git a/drivers/acpi/acpi_lpit.c b/drivers/acpi/acpi_lpit.c
new file mode 100644
index 0000000..38d760d
--- /dev/null
+++ b/drivers/acpi/acpi_lpit.c
@@ -0,0 +1,157 @@
+
+/*
+ * acpi_lpit.c - LPIT table processing functions
+ *
+ * Copyright (C) 2017 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/cpu.h>
+#include <linux/acpi.h>
+#include <asm/msr.h>
+#include <asm/tsc.h>
+
+struct lpit_residency_info {
+ struct acpi_generic_address gaddr;
+ u64 frequency;
+ void __iomem *iomem_addr;
+};
+
+/* Storage for an memory mapped and FFH based entries */
+static struct lpit_residency_info residency_info_mem;
+static struct lpit_residency_info residency_info_ffh;
+
+static int lpit_read_residency_counter_us(u64 *counter, bool io_mem)
+{
+ int err;
+
+ if (io_mem) {
+ u32 count;
+
+ count = readl(residency_info_mem.iomem_addr);
+ *counter = div64_u64(count * 1000000ULL, residency_info_mem.frequency);
+ return 0;
+ }
+
+ err = rdmsrl_safe(residency_info_ffh.gaddr.address, counter);
+ if (!err) {
+ u64 mask = GENMASK_ULL(residency_info_ffh.gaddr.bit_offset +
+ residency_info_ffh.gaddr. bit_width - 1,
+ residency_info_ffh.gaddr.bit_offset);
+
+ *counter &= mask;
+ *counter >>= residency_info_ffh.gaddr.bit_offset;
+ *counter = div64_u64(*counter * 1000000ULL, residency_info_ffh.frequency);
+ return 0;
+ }
+
+ return -ENODATA;
+}
+
+static ssize_t low_power_idle_system_residency_us_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ u64 counter;
+ int ret;
+
+ ret = lpit_read_residency_counter_us(&counter, true);
+ if (ret)
+ return ret;
+
+ return sprintf(buf, "%llu\n", counter);
+}
+static DEVICE_ATTR_RO(low_power_idle_system_residency_us);
+
+static ssize_t low_power_idle_cpu_residency_us_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ u64 counter;
+ int ret;
+
+ ret = lpit_read_residency_counter_us(&counter, false);
+ if (ret)
+ return ret;
+
+ return sprintf(buf, "%llu\n", counter);
+}
+static DEVICE_ATTR_RO(low_power_idle_cpu_residency_us);
+
+int lpit_read_residency_count_address(u64 *address)
+{
+ if (!residency_info_mem.gaddr.address)
+ return -EINVAL;
+
+ *address = residency_info_mem.gaddr.address;
+
+ return 0;
+}
+
+static void lpit_update_residency(struct lpit_residency_info *info,
+ struct acpi_lpit_native *lpit_native)
+{
+ info->frequency = lpit_native->counter_frequency ?
+ lpit_native->counter_frequency : tsc_khz * 1000;
+ if (!info->frequency)
+ info->frequency = 1;
+
+ info->gaddr = lpit_native->residency_counter;
+ if (info->gaddr.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
+ info->iomem_addr = ioremap_nocache(info->gaddr.address,
+ info->gaddr.bit_width / 8);
+ if (!info->iomem_addr)
+ return;
+
+ /* Silently fail, if cpuidle attribute group is not present */
+ sysfs_add_file_to_group(&cpu_subsys.dev_root->kobj,
+ &dev_attr_low_power_idle_system_residency_us.attr,
+ "cpuidle");
+ } else if (info->gaddr.space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) {
+ /* Silently fail, if cpuidle attribute group is not present */
+ sysfs_add_file_to_group(&cpu_subsys.dev_root->kobj,
+ &dev_attr_low_power_idle_cpu_residency_us.attr,
+ "cpuidle");
+ }
+}
+
+static void lpit_process(u64 begin, u64 end)
+{
+ while (begin + sizeof(struct acpi_lpit_native) < end) {
+ struct acpi_lpit_native *lpit_native = (struct acpi_lpit_native *)begin;
+
+ if (!lpit_native->header.type && !lpit_native->header.flags) {
+ if (lpit_native->residency_counter.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY &&
+ !residency_info_mem.gaddr.address) {
+ lpit_update_residency(&residency_info_mem, lpit_native);
+ } else if (lpit_native->residency_counter.space_id == ACPI_ADR_SPACE_FIXED_HARDWARE &&
+ !residency_info_ffh.gaddr.address) {
+ lpit_update_residency(&residency_info_ffh, lpit_native);
+ }
+ }
+ begin += lpit_native->header.length;
+ }
+}
+
+void acpi_init_lpit(void)
+{
+ acpi_status status;
+ u64 lpit_begin;
+ struct acpi_table_lpit *lpit;
+
+ status = acpi_get_table(ACPI_SIG_LPIT, 0, (struct acpi_table_header **)&lpit);
+
+ if (ACPI_FAILURE(status))
+ return;
+
+ lpit_begin = (u64)lpit + sizeof(*lpit);
+ lpit_process(lpit_begin, lpit_begin + lpit->header.length);
+}
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 602f8ff..3f05d43 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -15,6 +15,8 @@
#include <linux/dma-mapping.h>
#include <linux/platform_data/x86/apple.h>
+#include <acpi/acpi_lpit.h>
+
#include <asm/pgtable.h>
#include "internal.h"
@@ -2122,6 +2124,7 @@ int __init acpi_scan_init(void)
acpi_int340x_thermal_init();
acpi_amba_init();
acpi_watchdog_init();
+ acpi_init_lpit();
acpi_scan_add_handler(&generic_device_handler);
diff --git a/include/acpi/acpi_lpit.h b/include/acpi/acpi_lpit.h
new file mode 100644
index 0000000..5d5285a
--- /dev/null
+++ b/include/acpi/acpi_lpit.h
@@ -0,0 +1,34 @@
+/*
+ * acpi_lpit.h - LPIT table processing functions interface
+ *
+ * Copyright (C) 2017 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef ACPI_LPIT_H
+#define ACPI_LPIT_H
+
+#ifdef CONFIG_ACPI_LPIT
+
+void acpi_init_lpit(void);
+int lpit_read_residency_count_address(u64 *address);
+
+#else
+
+static inline void acpi_init_lpit(void) { }
+
+static inline int lpit_read_residency_count_address(u64 *address)
+{
+ return -EINVAL;
+}
+
+#endif
+#endif
--
2.7.5
^ permalink raw reply related
* [rcu:rcu/next 31/31] kernel/rcu/tree.c:764:75: error: macro "trace_rcu_dyntick" passed 4 arguments, but takes just 3
From: kbuild test robot @ 2017-10-04 23:40 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: kbuild-all, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 5825 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
head: ff423bbbe3d93b15a89d14de24a90937814cda16
commit: ff423bbbe3d93b15a89d14de24a90937814cda16 [31/31] rcu: Add ->dynticks field to rcu_dyntick trace event
config: i386-randconfig-x001-201740 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout ff423bbbe3d93b15a89d14de24a90937814cda16
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/rcu/tree.c: In function 'rcu_eqs_enter_common':
>> kernel/rcu/tree.c:764:75: error: macro "trace_rcu_dyntick" passed 4 arguments, but takes just 3
trace_rcu_dyntick(TPS("Start"), rdtp->dynticks_nesting, 0, rdtp->dynticks);
^
>> kernel/rcu/tree.c:764:2: error: 'trace_rcu_dyntick' undeclared (first use in this function)
trace_rcu_dyntick(TPS("Start"), rdtp->dynticks_nesting, 0, rdtp->dynticks);
^~~~~~~~~~~~~~~~~
kernel/rcu/tree.c:764:2: note: each undeclared identifier is reported only once for each function it appears in
kernel/rcu/tree.c:770:100: error: macro "trace_rcu_dyntick" passed 4 arguments, but takes just 3
trace_rcu_dyntick(TPS("Error on entry: not idle task"), rdtp->dynticks_nesting, 0, rdtp->dynticks);
^
kernel/rcu/tree.c: In function 'rcu_nmi_exit':
kernel/rcu/tree.c:883:107: error: macro "trace_rcu_dyntick" passed 4 arguments, but takes just 3
trace_rcu_dyntick(TPS("--="), rdtp->dynticks_nmi_nesting, rdtp->dynticks_nmi_nesting - 2, rdtp->dynticks);
^
kernel/rcu/tree.c:883:3: error: 'trace_rcu_dyntick' undeclared (first use in this function)
trace_rcu_dyntick(TPS("--="), rdtp->dynticks_nmi_nesting, rdtp->dynticks_nmi_nesting - 2, rdtp->dynticks);
^~~~~~~~~~~~~~~~~
kernel/rcu/tree.c:890:82: error: macro "trace_rcu_dyntick" passed 4 arguments, but takes just 3
trace_rcu_dyntick(TPS("Startirq"), rdtp->dynticks_nmi_nesting, 0, rdtp->dynticks);
^
kernel/rcu/tree.c: In function 'rcu_eqs_exit_common':
kernel/rcu/tree.c:956:78: error: macro "trace_rcu_dyntick" passed 4 arguments, but takes just 3
trace_rcu_dyntick(TPS("End"), rdtp->dynticks_nesting, newval, rdtp->dynticks);
^
kernel/rcu/tree.c:956:2: error: 'trace_rcu_dyntick' undeclared (first use in this function)
trace_rcu_dyntick(TPS("End"), rdtp->dynticks_nesting, newval, rdtp->dynticks);
^~~~~~~~~~~~~~~~~
kernel/rcu/tree.c:962:104: error: macro "trace_rcu_dyntick" passed 4 arguments, but takes just 3
trace_rcu_dyntick(TPS("Error on exit: not idle task"), rdtp->dynticks_nesting, newval, rdtp->dynticks);
^
kernel/rcu/tree.c: In function 'rcu_nmi_enter':
kernel/rcu/tree.c:1064:56: error: macro "trace_rcu_dyntick" passed 4 arguments, but takes just 3
rdtp->dynticks_nmi_nesting + incby, rdtp->dynticks);
^
kernel/rcu/tree.c:1062:2: error: 'trace_rcu_dyntick' undeclared (first use in this function)
trace_rcu_dyntick(incby == 1 ? TPS("Endirq") : TPS("++="),
^~~~~~~~~~~~~~~~~
vim +/trace_rcu_dyntick +764 kernel/rcu/tree.c
750
751 /*
752 * rcu_eqs_enter_common - current CPU is entering an extended quiescent state
753 *
754 * Enter idle, doing appropriate accounting. The caller must have
755 * disabled interrupts.
756 */
757 static void rcu_eqs_enter_common(bool user)
758 {
759 struct rcu_state *rsp;
760 struct rcu_data *rdp;
761 struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
762
763 RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_eqs_enter_common() invoked with irqs enabled!!!");
> 764 trace_rcu_dyntick(TPS("Start"), rdtp->dynticks_nesting, 0, rdtp->dynticks);
765 if (IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
766 !user && !is_idle_task(current)) {
767 struct task_struct *idle __maybe_unused =
768 idle_task(smp_processor_id());
769
770 trace_rcu_dyntick(TPS("Error on entry: not idle task"), rdtp->dynticks_nesting, 0, rdtp->dynticks);
771 rcu_ftrace_dump(DUMP_ORIG);
772 WARN_ONCE(1, "Current pid: %d comm: %s / Idle pid: %d comm: %s",
773 current->pid, current->comm,
774 idle->pid, idle->comm); /* must be idle task! */
775 }
776 for_each_rcu_flavor(rsp) {
777 rdp = this_cpu_ptr(rsp->rda);
778 do_nocb_deferred_wakeup(rdp);
779 }
780 rcu_prepare_for_idle();
781 rdtp->dynticks_nesting = 0;
782 rcu_dynticks_eqs_enter();
783 rcu_dynticks_task_enter();
784
785 /*
786 * It is illegal to enter an extended quiescent state while
787 * in an RCU read-side critical section.
788 */
789 RCU_LOCKDEP_WARN(lock_is_held(&rcu_lock_map),
790 "Illegal idle entry in RCU read-side critical section.");
791 RCU_LOCKDEP_WARN(lock_is_held(&rcu_bh_lock_map),
792 "Illegal idle entry in RCU-bh read-side critical section.");
793 RCU_LOCKDEP_WARN(lock_is_held(&rcu_sched_lock_map),
794 "Illegal idle entry in RCU-sched read-side critical section.");
795 }
796
---
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: 34831 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.