* Re: [PATCH net-next] tcp: provide SYN headers for passive connections
From: Eric Dumazet @ 2015-05-05 21:02 UTC (permalink / raw)
To: David Miller
Cc: emunson-JqFfY2XvxFXQT0dZR+AlfA, tom-BjP2VixgY4xUbtYUoyoikg,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150505.160535.1034497188259706110.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, 2015-05-05 at 16:05 -0400, David Miller wrote:
> Applied, but I think you should give maybe a little bit more thought
> into the behavior when a not-large-enough buffer is supplied by the
> user.
>
> Since we're talking about things on the order of 60 bytes or so at
> most, it seems clear to me that signalling an error is probably the
> most advisable thing to do in this situation.
>
> Maybe you could signal an error, yet write the actual length to
> "optlen". That way the user can figure out how much they need. Then
> they at least would have the option of retrying with a larger buffer.
Seems fine to me, I'll provide a patch implementing your suggestions.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: provide SYN headers for passive connections
From: David Miller @ 2015-05-05 20:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: emunson, tom, linux-api, netdev
In-Reply-To: <1430714086.3711.165.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 03 May 2015 21:34:46 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> This patch allows a server application to get the TCP SYN headers for
> its passive connections. This is useful if the server is doing
> fingerprinting of clients based on SYN packet contents.
>
> Two socket options are added: TCP_SAVE_SYN and TCP_SAVED_SYN.
>
> The first is used on a socket to enable saving the SYN headers
> for child connections. This can be set before or after the listen()
> call.
>
> The latter is used to retrieve the SYN headers for passive connections,
> if the parent listener has enabled TCP_SAVE_SYN.
>
> TCP_SAVED_SYN is read once, it frees the saved SYN headers.
>
> The data returned in TCP_SAVED_SYN are network (IPv4/IPv6) and TCP
> headers.
>
> Original patch was written by Tom Herbert, I changed it to not hold
> a full skb (and associated dst and conntracking reference).
>
> We have used such patch for about 3 years at Google.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, but I think you should give maybe a little bit more thought
into the behavior when a not-large-enough buffer is supplied by the
user.
Since we're talking about things on the order of 60 bytes or so at
most, it seems clear to me that signalling an error is probably the
most advisable thing to do in this situation.
Maybe you could signal an error, yet write the actual length to
"optlen". That way the user can figure out how much they need. Then
they at least would have the option of retrying with a larger buffer.
^ permalink raw reply
* Re: [PATCH] ipc/sem: 64bit union semun definition
From: Arnd Bergmann @ 2015-05-05 19:37 UTC (permalink / raw)
To: a22017-3WKxDLwmzFNWk0Htik3J/w
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1430850523-7522-1-git-send-email-a22017-3WKxDLwmzFNWk0Htik3J/w@public.gmane.org>
On Tuesday 05 May 2015 11:28:43 a22017-3WKxDLwmzFNWk0Htik3J/w@public.gmane.org wrote:
> From: Ling-Juan Sun <a22017-3WKxDLwmzFNWk0Htik3J/w@public.gmane.org>
>
> The member of semun semid_ds has new definition
> semid64_ds for 64bit architectures.
>
> Signed-off-by: Ling-Juan Sun <a22017-3WKxDLwmzFNWk0Htik3J/w@public.gmane.org>
>
Please describe in more detail what this is needed for. The way I
understood this, used space would always define union semun
to define semid_ds, but that would normally match the kernel's
semid64_ds.
Also, what is the connection with 64-bit architectures here?
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] clone: Support passing tls argument via C rather than pt_regs magic
From: Thomas Gleixner @ 2015-05-05 18:53 UTC (permalink / raw)
To: Josh Triplett
Cc: Andy Lutomirski, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linus Torvalds, linux-api, linux-kernel, x86
In-Reply-To: <20150421174711.GA5127@jtriplet-mobl1>
On Tue, 21 Apr 2015, Josh Triplett wrote:
>
> Signed-off-by: Josh Triplett <josh@joshtriplett.org>
> Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Can you please clarify that SOB chain? It does not make any sense.
Thanks,
tglx
^ permalink raw reply
* [PATCH] ipc/sem: 64bit union semun definition
From: a22017 @ 2015-05-05 18:28 UTC (permalink / raw)
To: akpm, linux-api, linux-kernel; +Cc: Ling-Juan Sun
From: Ling-Juan Sun <a22017@motorola.com>
The member of semun semid_ds has new definition
semid64_ds for 64bit architectures.
Signed-off-by: Ling-Juan Sun <a22017@motorola.com>
---
include/uapi/linux/sem.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/uapi/linux/sem.h b/include/uapi/linux/sem.h
index dd73b90..e9ab2a5 100644
--- a/include/uapi/linux/sem.h
+++ b/include/uapi/linux/sem.h
@@ -50,6 +50,15 @@ union semun {
void __user *__pad;
};
+/* arg for semctl 64 bit system calls. */
+union semun64 {
+ int val; /* value for SETVAL */
+ struct semid64_ds __user *buf; /* buffer for IPC_STAT & IPC_SET */
+ unsigned short __user *array; /* array for GETALL & SETALL */
+ struct seminfo __user *__buf; /* buffer for IPC_INFO */
+ void __user *__pad;
+};
+
struct seminfo {
int semmap;
int semmni;
--
2.1.1
^ permalink raw reply related
* Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings
From: Maxime Coquelin @ 2015-05-05 17:24 UTC (permalink / raw)
To: Daniel Thompson, Philipp Zabel, Rob Herring,
devicetree@vger.kernel.org
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Linus Walleij, Arnd Bergmann, Stefan Agner, Peter Meerwald,
Paul Bolle, Peter Hurley, Andy Shevchenko, Chanwoo Choi,
Russell King, Daniel Lezcano, Joe Perches, Vladimir Zapolskiy,
Jonathan Corbet, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Thomas Gleixner
In-Reply-To: <5548EAC1.7010002@linaro.org>
2015-05-05 18:07 GMT+02:00 Daniel Thompson <daniel.thompson@linaro.org>:
> On 05/05/15 16:42, Philipp Zabel wrote:
>>
>> Am Dienstag, den 05.05.2015, 17:19 +0200 schrieb Maxime Coquelin:
>>>>>
>>>>> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>>>>>
>>>>> #define GPIOA 0
>>>>> #define GPIOB 1
>>>>> ...
>>>>> #define LTDC 186
>>
>>
>> That looks a bit fragile.
>> At least the defines for the indices should be properly namespaced,
>> check out include/dt-bindings/gpio/tegra-gpio.h for a similar case.
>
>
> Good point.
>
>>>>> #define STM32F4_RESET(x) (x + 128)
>>>>> #define STM32F4_CLOCK(x) (x + 384)
>
>
> Thinking more about this point, if we are going to follow hardware if might
> be better to have:
>
> #define STM32F4_RCC_AHB1_GPIOA 0
> #define STM32F4_RCC_AHB1_GPIOA 1
> ...
> #define STM32F4_RCC_APB2_LTDC 26
>
>
> #define STM32F4_AHB1_RESET(x) (STM32F4_RCC_AHB1_##x##_BIT + (0x10 * 8))
> #define STM32F4_AHB2_RESET(x) (STM32F4_RCC_AHB2_##x##_BIT + (0x14 * 8))
> ...
> #define STM32F4_APB2_RESET(x) (STM32F4_RCC_APB2_##x##_BIT + (0x24 * 8))
>
> Its more typing (or copy 'n pasting) by at least every number now maps
> directly to the datasheet.
As said in Philipp's reply, I like the idea.
Regards,
Maxime
>
>
>
>>>>>
>>>>> Then, in DT, a reset would be described like this:
>>>>>
>>>>> timer2 {
>>>>> resets = <&rcc STM32F4_RESET(TIM2)>;
>>>>> };
>>>>>
>>>>> Phillip, Daniel, does that look acceptable to you?
>>>>
>>>>
>>>>
>>>> Doesn't look unreasonable.
>>>>
>>>> I am a little uneasy simply because there are very few similar header
>>>> files
>>>> in that directory but I haven't thought of a better idea.
>>>
>>>
>>> Since this file will be shared by both clock and reset drivers, I
>>> don't see better option.
>>> I will implement it in v8 if Philipp agrees.
>>
>>
>> Are the device tree maintainers happy with this idiom spreading?
>> Except for the point above, I think this is acceptable.
>>
>> regards
>> Philipp
>>
>
^ permalink raw reply
* Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings
From: Maxime Coquelin @ 2015-05-05 17:22 UTC (permalink / raw)
To: Philipp Zabel, devicetree@vger.kernel.org, Rob Herring
Cc: Daniel Thompson, Uwe Kleine-König, Andreas Färber,
Geert Uytterhoeven, Linus Walleij, Arnd Bergmann, Stefan Agner,
Peter Meerwald, Paul Bolle, Peter Hurley, Andy Shevchenko,
Chanwoo Choi, Russell King, Daniel Lezcano, Joe Perches,
Vladimir Zapolskiy, Jonathan Corbet, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala
In-Reply-To: <1430840557.3035.60.camel@pengutronix.de>
2015-05-05 17:42 GMT+02:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Am Dienstag, den 05.05.2015, 17:19 +0200 schrieb Maxime Coquelin:
>> >> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>> >>
>> >> #define GPIOA 0
>> >> #define GPIOB 1
>> >> ...
>> >> #define LTDC 186
>
> That looks a bit fragile.
> At least the defines for the indices should be properly namespaced,
> check out include/dt-bindings/gpio/tegra-gpio.h for a similar case.
Thanks, I will prefix them with the proper namespace, Daniel proposal
is fine to me.
>
>> >> #define STM32F4_RESET(x) (x + 128)
>> >> #define STM32F4_CLOCK(x) (x + 384)
>> >>
>> >> Then, in DT, a reset would be described like this:
>> >>
>> >> timer2 {
>> >> resets = <&rcc STM32F4_RESET(TIM2)>;
>> >> };
>> >>
>> >> Phillip, Daniel, does that look acceptable to you?
>> >
>> >
>> > Doesn't look unreasonable.
>> >
>> > I am a little uneasy simply because there are very few similar header files
>> > in that directory but I haven't thought of a better idea.
>>
>> Since this file will be shared by both clock and reset drivers, I
>> don't see better option.
>> I will implement it in v8 if Philipp agrees.
>
> Are the device tree maintainers happy with this idiom spreading?
> Except for the point above, I think this is acceptable.
Ok good. Let's see what DT maintainers thinks about that.
Regards,
Maxime
>
> regards
> Philipp
>
^ permalink raw reply
* Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings
From: Daniel Thompson @ 2015-05-05 16:07 UTC (permalink / raw)
To: Philipp Zabel, Maxime Coquelin
Cc: Mark Rutland, linux-doc@vger.kernel.org, Linus Walleij,
Will Deacon, Stefan Agner, Nikolay Borisov, Peter Meerwald,
linux-api@vger.kernel.org, Jiri Slaby, Mauro Carvalho Chehab,
Linux-Arch, Russell King, Pawel Moll, Jonathan Corbet, Lee Jones,
Daniel Lezcano, Chanwoo Choi, Andy Shevchenko, Antti Palosaari,
Geert Uytterhoeven, linux-serial@vger.kernel.org
In-Reply-To: <1430840557.3035.60.camel@pengutronix.de>
On 05/05/15 16:42, Philipp Zabel wrote:
> Am Dienstag, den 05.05.2015, 17:19 +0200 schrieb Maxime Coquelin:
>>>> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>>>>
>>>> #define GPIOA 0
>>>> #define GPIOB 1
>>>> ...
>>>> #define LTDC 186
>
> That looks a bit fragile.
> At least the defines for the indices should be properly namespaced,
> check out include/dt-bindings/gpio/tegra-gpio.h for a similar case.
Good point.
>>>> #define STM32F4_RESET(x) (x + 128)
>>>> #define STM32F4_CLOCK(x) (x + 384)
Thinking more about this point, if we are going to follow hardware if
might be better to have:
#define STM32F4_RCC_AHB1_GPIOA 0
#define STM32F4_RCC_AHB1_GPIOA 1
...
#define STM32F4_RCC_APB2_LTDC 26
#define STM32F4_AHB1_RESET(x) (STM32F4_RCC_AHB1_##x##_BIT + (0x10 * 8))
#define STM32F4_AHB2_RESET(x) (STM32F4_RCC_AHB2_##x##_BIT + (0x14 * 8))
...
#define STM32F4_APB2_RESET(x) (STM32F4_RCC_APB2_##x##_BIT + (0x24 * 8))
Its more typing (or copy 'n pasting) by at least every number now maps
directly to the datasheet.
>>>>
>>>> Then, in DT, a reset would be described like this:
>>>>
>>>> timer2 {
>>>> resets = <&rcc STM32F4_RESET(TIM2)>;
>>>> };
>>>>
>>>> Phillip, Daniel, does that look acceptable to you?
>>>
>>>
>>> Doesn't look unreasonable.
>>>
>>> I am a little uneasy simply because there are very few similar header files
>>> in that directory but I haven't thought of a better idea.
>>
>> Since this file will be shared by both clock and reset drivers, I
>> don't see better option.
>> I will implement it in v8 if Philipp agrees.
>
> Are the device tree maintainers happy with this idiom spreading?
> Except for the point above, I think this is acceptable.
>
> regards
> Philipp
>
^ permalink raw reply
* Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings
From: Philipp Zabel @ 2015-05-05 15:42 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Mark Rutland, linux-doc@vger.kernel.org, Linus Walleij,
Will Deacon, Stefan Agner, Nikolay Borisov, Peter Meerwald,
linux-api@vger.kernel.org, Jiri Slaby, Mauro Carvalho Chehab,
Linux-Arch, Daniel Thompson, Russell King, Pawel Moll,
Jonathan Corbet, Lee Jones, Daniel Lezcano, Chanwoo Choi,
Andy Shevchenko, Antti Palosaari, Geert Uytterhoeven
In-Reply-To: <CALszF6DyUA7Wr2qo4sASFBTRwwjhGAkFKRYnY+1UwHmf4nTj5w@mail.gmail.com>
Am Dienstag, den 05.05.2015, 17:19 +0200 schrieb Maxime Coquelin:
> >> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
> >>
> >> #define GPIOA 0
> >> #define GPIOB 1
> >> ...
> >> #define LTDC 186
That looks a bit fragile.
At least the defines for the indices should be properly namespaced,
check out include/dt-bindings/gpio/tegra-gpio.h for a similar case.
> >> #define STM32F4_RESET(x) (x + 128)
> >> #define STM32F4_CLOCK(x) (x + 384)
> >>
> >> Then, in DT, a reset would be described like this:
> >>
> >> timer2 {
> >> resets = <&rcc STM32F4_RESET(TIM2)>;
> >> };
> >>
> >> Phillip, Daniel, does that look acceptable to you?
> >
> >
> > Doesn't look unreasonable.
> >
> > I am a little uneasy simply because there are very few similar header files
> > in that directory but I haven't thought of a better idea.
>
> Since this file will be shared by both clock and reset drivers, I
> don't see better option.
> I will implement it in v8 if Philipp agrees.
Are the device tree maintainers happy with this idiom spreading?
Except for the point above, I think this is acceptable.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings
From: Maxime Coquelin @ 2015-05-05 15:19 UTC (permalink / raw)
To: Daniel Thompson
Cc: Mark Rutland, linux-doc@vger.kernel.org, Linus Walleij,
Will Deacon, Stefan Agner, Nikolay Borisov, Peter Meerwald,
linux-api@vger.kernel.org, Jiri Slaby, Mauro Carvalho Chehab,
Linux-Arch, Russell King, Pawel Moll, Jonathan Corbet, Lee Jones,
Daniel Lezcano, Chanwoo Choi, Andy Shevchenko, Antti Palosaari,
Geert Uytterhoeven, linux-serial@vger.kernel.org
In-Reply-To: <5548CEA2.8020807@linaro.org>
2015-05-05 16:07 GMT+02:00 Daniel Thompson <daniel.thompson@linaro.org>:
> On 04/05/15 12:25, Maxime Coquelin wrote:
>>
>> 2015-05-02 12:01 GMT+02:00 Daniel Thompson <daniel.thompson@linaro.org>:
>>>
>>> On 02/05/15 08:55, Maxime Coquelin wrote:
>>>>
>>>>
>>>> 2015-05-01 10:08 GMT+02:00 Daniel Thompson <daniel.thompson@linaro.org>:
>>>>>
>>>>>
>>>>> On 30/04/15 17:20, Maxime Coquelin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> This adds documentation of device tree bindings for the
>>>>>> STM32 reset controller.
>>>>>>
>>>>>> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>>> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/reset/st,stm32-rcc.txt | 107
>>>>>> +++++++++++++++++++++
>>>>>> 1 file changed, 107 insertions(+)
>>>>>> create mode 100644
>>>>>> Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>>> b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..c1b0f8d
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>>> @@ -0,0 +1,107 @@
>>>>>> +STMicroelectronics STM32 Peripheral Reset Controller
>>>>>> +====================================================
>>>>>> +
>>>>>> +The RCC IP is both a reset and a clock controller. This documentation
>>>>>> only
>>>>>> +documents the reset part.
>>>>>> +
>>>>>> +Please also refer to reset.txt in this directory for common reset
>>>>>> +controller binding usage.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible: Should be "st,stm32-rcc"
>>>>>> +- reg: should be register base and length as documented in the
>>>>>> + datasheet
>>>>>> +- #reset-cells: 1, see below
>>>>>> +
>>>>>> +example:
>>>>>> +
>>>>>> +rcc: reset@40023800 {
>>>>>> + #reset-cells = <1>;
>>>>>> + compatible = "st,stm32-rcc";
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Do you intend the clock driver to use the same compatible string (given
>>>>> it
>>>>> is the same bit of hardware).
>>>>>
>>>>> If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me
>>>>> that
>>>>> the register layout of the PLLs and dividers can be the same on the f7
>>>>> parts
>>>>> (and later).
>>>>
>>>>
>>>>
>>>> I agree we need a compatible dedicate to f4 series for clocks, and
>>>> maybe even one for f429 (to be checked).
>>>> For the reset part, we don't have this need.
>>>>
>>>> So either we use only "st,stm32f4" as you suggest, or we can have both
>>>> in device tree:
>>>>
>>>> rcc: reset@40023800 {
>>>> #reset-cells = <1>;
>>>> compatible = "st,stm32f4-rcc", "st,stm32-rcc";
>>>> reg = <0x40023800 0x400>;
>>>> };
>>>>
>>>> What do you think?
>>>
>>>
>>>
>>> Having both makes sense. The reset driver probably doesn't care about
>>> differences between F4 and F7 (I know very little about F7 but I can't
>>> think
>>> of any obvious h/ware evolution that would confuse the current reset
>>> driver).
>>>
>>>
>>>>>> + reg = <0x40023800 0x400>;
>>>>>> +};
>>>>>> +
>>>>>> +Specifying softreset control of devices
>>>>>> +=======================================
>>>>>> +
>>>>>> +Device nodes should specify the reset channel required in their
>>>>>> "resets"
>>>>>> +property, containing a phandle to the reset device node and an index
>>>>>> specifying
>>>>>> +which channel to use.
>>>>>> +The index is the bit number within the RCC registers bank, starting
>>>>>> from
>>>>>> RCC
>>>>>> +base address.
>>>>>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>>>>>> +Where bit_offset is the bit offset within the register.
>>>>>> +For example, for CRC reset:
>>>>>> + crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32
>>>>>> +
>>>>>> 12
>>>>>> = 140
>>>>>> +
>>>>>> +example:
>>>>>> +
>>>>>> + timer2 {
>>>>>> + resets = <&rcc 256>;
>>>>>> + };
>>>>>> +
>>>>>> +List of valid indices for STM32F429:
>>>>>> + - gpioa: 128
>>>>>> + - gpiob: 129
>>>>>> ...
>>>>>> <snip>
>>>>>> ...
>>>>>> + - sai1: 310
>>>>>> + - ltdc: 314
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> These numbers are stable for all STM32F4 family parts. Should this
>>>>> table
>>>>> go
>>>>> into a dt-bindings header file?
>>>>>
>>>>
>>>> This has already been discussed with Philipp and Arnd in earlier
>>>> versions of this series [0].
>>>> I initially created a header file, and we decided going this way
>>>> finally.
>>>
>>>
>>>
>>> Thanks for the link. I had overlooked that (I only really started paying
>>> attention at v5; I should probably have looked further back before
>>> commenting).
>>>
>>> However...
>>>
>>> Arnd's concerns about mergability of headers can also be met by using
>>> h/ware
>>> values in the header file can't there. To be honest my comment was pretty
>>> heavily influenced after having read a recent patch from Rob Herring (
>>> https://lkml.org/lkml/2015/5/1/14 ) which does exactly this.
>>>
>>> The main reason I got interested in having a header is that the reset
>>> bits
>>> and the clock gate bits are encoded using the same bit patterns so I
>>> wondering it we could express that only once.
>>
>>
>> Ok, I understand your need, and it makes sense.
>> The problem is that the values defined today cannot be re-used
>> directly for clocks.
>> Since the calculation is starting from rcc base, there is a 128 offset.
>>
>> To re-use the same values, maybe we should create a mfd dt-binding header
>> file.
>> It would contain the bits definition starting from 0, and define
>> macros for both reset and clocks to add the offsets.
>>
>> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>>
>> #define GPIOA 0
>> #define GPIOB 1
>> ...
>> #define LTDC 186
>>
>> #define STM32F4_RESET(x) (x + 128)
>> #define STM32F4_CLOCK(x) (x + 384)
>>
>> Then, in DT, a reset would be described like this:
>>
>> timer2 {
>> resets = <&rcc STM32F4_RESET(TIM2)>;
>> };
>>
>> Phillip, Daniel, does that look acceptable to you?
>
>
> Doesn't look unreasonable.
>
> I am a little uneasy simply because there are very few similar header files
> in that directory but I haven't thought of a better idea.
Since this file will be shared by both clock and reset drivers, I
don't see better option.
I will implement it in v8 if Philipp agrees.
Thanks,
Maxime
>
>
> Daniel.
>
>
>
>>
>> Kind regards,
>> Maxime
>>>
>>>
>>> I guess it doesn't matter that much, especially given there is only one
>>> .dtsi file, and we can add a header later and remain binary compatible.
>>> However if the same number set does end up repeated in different .dtsi
>>> files
>>> I think that would motivate adding a header for F4 family.
>>>
>>>
>>> Daniel.
>>>
>
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Steve Grubb @ 2015-05-05 15:16 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
pmoore-H+wXaHxf7aLQT0dZR+AlfA, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
eparis-FjpueFixGhCM4zKIHC2jIg,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <87pp6fhy4c.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On Tuesday, May 05, 2015 09:56:03 AM Eric W. Biederman wrote:
> Steve Grubb <sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> > The requirements for auditing of containers should be derived from VPP. In
> > it, it asks for selectable auditing, selective audit, and selective audit
> > review. What this means is that we need the container and all its
> > children to have one identifier that is inserted into all the events that
> > are associated with the container.
>
> That is technically impossible. Nested containers exist.
OK, then lets talk about that, too. When something is 2 layers deep, the
outside world cannot make sense of it. The inner one can be a loopback mounted
file in the outer one. That means that I need the container itself to be
responsible for events so that things are recorded using paths, uids, and pids
that make sense to it. It can enrich the events and send them to the outer
container.
> That is when container G is nested in container F which is in turn
> nested in container E which is in turn nested in container D which is in
> turn nested in container C which is in turn nested in container B which
> is nested in container A there is no one label you can put on audit
> messages from container G which is the ``correct'' one.
>
> Or are you proposing that something in container G have labels
> A B C D E F G included on every audit message?
We need to have audit events to either be globally tagged so that the outside
world understand what happening no matter how deep. Or we need each layer to
be responsible for itself. This means having an audit rule match engine for
each namespace like netfilter is to networking.
> That introduces enough complexity in generating and parsing the messages I
> wouldn't trust those messages as the least bug in generation and parsing
> would be a security issue.
That goes with the territory.
> What is the world is VPP?
Virtualization Protection Profile. Before people say it doesn't apply, it kind
of does. It defines the necessary security mechanisms for either full blown
virt like QEMU/Xen based or it gives enough wiggle room for containers and
other types of VMs. Specifically, it defines the audit requirements needed for
this kind of technology.
> It sounds like something non-public thing. Certainly it has never been a
> part of the public container discussion and as such it appears to be
> completely ridiculous to bring up in a public discussion.
No, its a public thing. Audit requirements start in section 5.2:
https://www.niap-ccevs.org/pp/PP_SV_V1.0/
-Steve
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Eric W. Biederman @ 2015-05-05 14:56 UTC (permalink / raw)
To: Steve Grubb
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
pmoore-H+wXaHxf7aLQT0dZR+AlfA, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
eparis-FjpueFixGhCM4zKIHC2jIg,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <2487286.y6vyJ9A3er@x2>
Steve Grubb <sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> The requirements for auditing of containers should be derived from VPP. In it,
> it asks for selectable auditing, selective audit, and selective audit review.
> What this means is that we need the container and all its children to have one
> identifier that is inserted into all the events that are associated with the
> container.
That is technically impossible. Nested containers exist.
That is when container G is nested in container F which is in turn
nested in container E which is in turn nested in container D which is in
turn nested in container C which is in turn nested in container B which
is nested in container A there is no one label you can put on audit
messages from container G which is the ``correct'' one.
Or are you proposing that something in container G have labels
A B C D E F G included on every audit message? That introduces enough
complexity in generating and parsing the messages I wouldn't trust those
messages as the least bug in generation and parsing would be a security
issue.
What is the world is VPP? It sounds like something non-public thing.
Certainly it has never been a part of the public container discussion
and as such it appears to be completely ridiculous to bring up in a
public discussion.
Eric
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Steve Grubb @ 2015-05-05 14:46 UTC (permalink / raw)
To: Aristeu Rozanski
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
pmoore-H+wXaHxf7aLQT0dZR+AlfA, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
eparis-FjpueFixGhCM4zKIHC2jIg,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <20150505143119.GA4350-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tuesday, May 05, 2015 10:31:20 AM Aristeu Rozanski wrote:
> Hi Steve,
>
> On Tue, May 05, 2015 at 10:22:32AM -0400, Steve Grubb wrote:
> > The requirements for auditing of containers should be derived from VPP. In
> > it, it asks for selectable auditing, selective audit, and selective audit
> > review. What this means is that we need the container and all its
> > children to have one identifier that is inserted into all the events that
> > are associated with the container.
> >
> > With this, its possible to do a search for all events related to a
> > container. Its possible to exclude events from a container. Its possible
> > to not get any events.
> >
> > The requirements also call out for the identification of the subject. This
> > means that the event should be bound to a syscall such as clone, setns, or
> > unshare.
> >
> > Also, any user space events originating inside the container needs to have
> > the container ID added to the user space event - just like auid and
> > session id.
> >
> > Recording each instance of a name space is giving me something that I
> > cannot use to do queries required by the security target. Given these
> > events, how do I locate a web server event where it accesses a watched
> > file? That authentication failed? That an update within the container
> > failed?
> >
> > The requirements are that we have to log the creation, suspension,
> > migration, and termination of a container. The requirements are not on
> > the individual name space.
> >
> > Maybe I'm missing how these events give me that. But I'd like to hear how
> > I would be able to meet requirements with these 12 events.
>
> what about cases you don't use lxc, libvirt to create namespaces?
There's a pretty good chance that we don't care. We've had file system
namespace for about 8 or 9 years and we never needed to have a namespace
identifier added.
> It's easier if the logging is done by namespaces and in case they're created
> by any container manager, it can generate a new event notifying it
> created a container named "foo" with these namespaces: x, y, z, w and
> from that you can piece together everything that happened.
OK, if they are emitted they should be an auxiliary record to clone, setns, or
unshare system calls. But lets go down this path. We have 6 or so name spaces.
These identifiers will need to be added to every single event in the system so
that I can figure out what event belongs to which container.
> Userspace tools can change to adapt to using namespaces and the idea of
> container to make it easier to lookup for events instead of relying on a
> number that might not be there (think someone using unshare, ip netns, ...).
That's what I am trying to do...figure out how I can these identifiers to see if
this actually solves the problem. This is why I wanted to state the actual
requirements. Its easy to lose the overall view.
Also, I am concerned about how much extra disk space this is going to eat up.
> It was discussed in the past and having the concept of "container" in
> kernel space and it's not going to happen, so userspace should deal with
> it.
This is what I am asking for help with. How do I locate an authentication
event from container using the information in these events?
-Steve
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Aristeu Rozanski @ 2015-05-05 14:31 UTC (permalink / raw)
To: Steve Grubb
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
pmoore-H+wXaHxf7aLQT0dZR+AlfA, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
eparis-FjpueFixGhCM4zKIHC2jIg,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <2487286.y6vyJ9A3er@x2>
Hi Steve,
On Tue, May 05, 2015 at 10:22:32AM -0400, Steve Grubb wrote:
> The requirements for auditing of containers should be derived from VPP. In it,
> it asks for selectable auditing, selective audit, and selective audit review.
> What this means is that we need the container and all its children to have one
> identifier that is inserted into all the events that are associated with the
> container.
>
> With this, its possible to do a search for all events related to a container.
> Its possible to exclude events from a container. Its possible to not get any
> events.
>
> The requirements also call out for the identification of the subject. This
> means that the event should be bound to a syscall such as clone, setns, or
> unshare.
>
> Also, any user space events originating inside the container needs to have the
> container ID added to the user space event - just like auid and session id.
>
> Recording each instance of a name space is giving me something that I cannot
> use to do queries required by the security target. Given these events, how do
> I locate a web server event where it accesses a watched file? That
> authentication failed? That an update within the container failed?
>
> The requirements are that we have to log the creation, suspension, migration,
> and termination of a container. The requirements are not on the individual
> name space.
>
> Maybe I'm missing how these events give me that. But I'd like to hear how I
> would be able to meet requirements with these 12 events.
what about cases you don't use lxc, libvirt to create namespaces? It's
easier if the logging is done by namespaces and in case they're created
by any container manager, it can generate a new event notifying it
created a container named "foo" with these namespaces: x, y, z, w and
from that you can piece together everything that happened. Userspace
tools can change to adapt to using namespaces and the idea of container
to make it easier to lookup for events instead of relying on a number
that might not be there (think someone using unshare, ip netns, ...). It
was discussed in the past and having the concept of "container" in
kernel space and it's not going to happen, so userspace should deal with
it.
--
Aristeu
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Steve Grubb @ 2015-05-05 14:22 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
pmoore-H+wXaHxf7aLQT0dZR+AlfA, linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
eparis-FjpueFixGhCM4zKIHC2jIg,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
ebiederm-aS9lmoZGLiVWk0Htik3J/w
In-Reply-To: <11270b0b1afd0a25b108915673e1e1b38dfeeafa.1429252659.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hello,
I think there needs to be some more discussion around this. It seems like this
is not exactly recording things that are useful for audit.
On Friday, April 17, 2015 03:35:52 AM Richard Guy Briggs wrote:
> Log the creation and deletion of namespace instances in all 6 types of
> namespaces.
>
> Twelve new audit message types have been introduced:
> AUDIT_NS_INIT_MNT 1330 /* Record mount namespace instance creation
> */ AUDIT_NS_INIT_UTS 1331 /* Record UTS namespace instance
> creation */ AUDIT_NS_INIT_IPC 1332 /* Record IPC namespace
> instance creation */ AUDIT_NS_INIT_USER 1333 /* Record USER
> namespace instance creation */ AUDIT_NS_INIT_PID 1334 /* Record
> PID namespace instance creation */ AUDIT_NS_INIT_NET 1335 /*
> Record NET namespace instance creation */ AUDIT_NS_DEL_MNT 1336
> /* Record mount namespace instance deletion */ AUDIT_NS_DEL_UTS 1337
> /* Record UTS namespace instance deletion */ AUDIT_NS_DEL_IPC
> 1338 /* Record IPC namespace instance deletion */ AUDIT_NS_DEL_USER
> 1339 /* Record USER namespace instance deletion */ AUDIT_NS_DEL_PID
> 1340 /* Record PID namespace instance deletion */ AUDIT_NS_DEL_NET
> 1341 /* Record NET namespace instance deletion */
The requirements for auditing of containers should be derived from VPP. In it,
it asks for selectable auditing, selective audit, and selective audit review.
What this means is that we need the container and all its children to have one
identifier that is inserted into all the events that are associated with the
container.
With this, its possible to do a search for all events related to a container.
Its possible to exclude events from a container. Its possible to not get any
events.
The requirements also call out for the identification of the subject. This
means that the event should be bound to a syscall such as clone, setns, or
unshare.
Also, any user space events originating inside the container needs to have the
container ID added to the user space event - just like auid and session id.
Recording each instance of a name space is giving me something that I cannot
use to do queries required by the security target. Given these events, how do
I locate a web server event where it accesses a watched file? That
authentication failed? That an update within the container failed?
The requirements are that we have to log the creation, suspension, migration,
and termination of a container. The requirements are not on the individual
name space.
Maybe I'm missing how these events give me that. But I'd like to hear how I
would be able to meet requirements with these 12 events.
-Steve
> As suggested by Eric Paris, there are 12 message types, one for each of
> creation and deletion, one for each type of namespace so that text searches
> are easier in conjunction with the AUDIT_NS_INFO message type, being able
> to search for all records such as "netns=4 " and to avoid fields
> disappearing per message type to make ausearch more efficient.
>
> A typical startup would look roughly like:
>
> type=AUDIT_NS_INIT_UTS msg=audit(1408577534.868:5): pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_utsns=(none)
> utsns=-2 res=1 type=AUDIT_NS_INIT_USER msg=audit(1408577534.868:6): pid=1
> uid=0 auid=4294967295 ses=4294967295 subj=kernel dev=00:03
> old_userns=(none) userns=-3 res=1 type=AUDIT_NS_INIT_PID
> msg=audit(1408577534.868:7): pid=1 uid=0 auid=4294967295 ses=4294967295
> subj=kernel dev=00:03 old_pidns=(none) pidns=-4 res=1
> type=AUDIT_NS_INIT_MNT msg=audit(1408577534.868:8): pid=1 uid=0
> auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_mntns=(none)
> mntns=0 res=1 type=AUDIT_NS_INIT_IPC msg=audit(1408577534.868:9): pid=1
> uid=0 auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_ipcns=(none)
> ipcns=-1 res=1 type=AUDIT_NS_INIT_NET msg=audit(1408577533.500:10): pid=1
> uid=0 auid=4294967295 ses=4294967295 subj=kernel dev=00:03 old_netns=(none)
> netns=2 res=1
>
> And a CLONE action would result in:
> type=type=AUDIT_NS_INIT_NET msg=audit(1408577535.306:81): pid=481 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 dev=00:03
> old_netns=2 netns=3 res=1
>
> While deleting a namespace would result in:
> type=type=AUDIT_NS_DEL_MNT msg=audit(1408577552.221:85): pid=481 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 dev=00:03
> mntns=4 res=1
>
> If not "(none)", old_XXXns lists the namespace from which it was cloned.
>
> Signed-off-by: Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> fs/namespace.c | 13 +++++++++
> include/linux/audit.h | 8 +++++
> include/uapi/linux/audit.h | 12 ++++++++
> ipc/namespace.c | 12 ++++++++
> kernel/audit.c | 64
> ++++++++++++++++++++++++++++++++++++++++++++ kernel/pid_namespace.c |
> 13 +++++++++
> kernel/user_namespace.c | 13 +++++++++
> kernel/utsname.c | 12 ++++++++
> net/core/net_namespace.c | 12 ++++++++
> 9 files changed, 159 insertions(+), 0 deletions(-)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 182bc41..7b62543 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -24,6 +24,7 @@
> #include <linux/proc_ns.h>
> #include <linux/magic.h>
> #include <linux/bootmem.h>
> +#include <linux/audit.h>
> #include "pnode.h"
> #include "internal.h"
>
> @@ -2459,6 +2460,7 @@ dput_out:
>
> static void free_mnt_ns(struct mnt_namespace *ns)
> {
> + audit_log_ns_del(AUDIT_NS_DEL_MNT, ns->proc_inum);
> proc_free_inum(ns->proc_inum);
> put_user_ns(ns->user_ns);
> kfree(ns);
> @@ -2518,6 +2520,7 @@ struct mnt_namespace *copy_mnt_ns(unsigned long flags,
> struct mnt_namespace *ns, new_ns = alloc_mnt_ns(user_ns);
> if (IS_ERR(new_ns))
> return new_ns;
> + audit_log_ns_init(AUDIT_NS_INIT_MNT, ns->proc_inum, new_ns->proc_inum);
>
> namespace_lock();
> /* First pass: copy the tree topology */
> @@ -2830,6 +2833,16 @@ static void __init init_mount_tree(void)
> set_fs_root(current->fs, &root);
> }
>
> +/* log the ID of init mnt namespace after audit service starts */
> +static int __init mnt_ns_init_log(void)
> +{
> + struct mnt_namespace *init_mnt_ns = init_task.nsproxy->mnt_ns;
> +
> + audit_log_ns_init(AUDIT_NS_INIT_MNT, 0, init_mnt_ns->proc_inum);
> + return 0;
> +}
> +late_initcall(mnt_ns_init_log);
> +
> void __init mnt_init(void)
> {
> unsigned u;
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 71698ec..b28dfb0 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -484,6 +484,9 @@ extern void audit_log_ns_info(struct
task_struct
> *tsk); static inline void audit_log_ns_info(struct task_struct *tsk) {
> }
> #endif
> +extern void audit_log_ns_init(int type, unsigned int old_inum,
> + unsigned int inum);
> +extern void audit_log_ns_del(int type, unsigned int inum);
>
> extern int audit_update_lsm_rules(void);
>
> @@ -542,6 +545,11 @@ static inline void audit_log_task_info(struct
> audit_buffer *ab, { }
> static inline void audit_log_ns_info(struct task_struct *tsk)
> { }
> +static inline int audit_log_ns_init(int type, unsigned int old_inum,
> + unsigned int inum)
> +{ }
> +static inline int audit_log_ns_del(int type, unsigned int inum)
> +{ }
> #define audit_enabled 0
> #endif /* CONFIG_AUDIT */
> static inline void audit_log_string(struct audit_buffer *ab, const char
> *buf) diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 1ffb151..487cad6 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -111,6 +111,18 @@
> #define AUDIT_PROCTITLE 1327 /* Proctitle emit event */
> #define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes
*/
> #define AUDIT_NS_INFO 1329 /* Record process namespace IDs */
> +#define AUDIT_NS_INIT_MNT 1330 /* Record mount namespace instance
creation
> */ +#define AUDIT_NS_INIT_UTS 1331 /* Record UTS namespace instance
> creation */ +#define AUDIT_NS_INIT_IPC 1332 /* Record IPC namespace
> instance creation */ +#define AUDIT_NS_INIT_USER 1333 /* Record USER
> namespace instance creation */ +#define AUDIT_NS_INIT_PID 1334 /* Record
> PID namespace instance creation */ +#define AUDIT_NS_INIT_NET 1335 /*
> Record NET namespace instance creation */ +#define AUDIT_NS_DEL_MNT 1336
/*
> Record mount namespace instance deletion */ +#define
> AUDIT_NS_DEL_UTS 1337 /* Record UTS namespace instance deletion */
+#define
> AUDIT_NS_DEL_IPC 1338 /* Record IPC namespace instance deletion */
+#define
> AUDIT_NS_DEL_USER 1339 /* Record USER namespace instance deletion */
> +#define AUDIT_NS_DEL_PID 1340 /* Record PID namespace instance
deletion */
> +#define AUDIT_NS_DEL_NET 1341 /* Record NET namespace instance deletion
*/
>
> #define AUDIT_AVC 1400 /* SE Linux avc denial or grant */
> #define AUDIT_SELINUX_ERR 1401 /* Internal SE Linux Errors */
> diff --git a/ipc/namespace.c b/ipc/namespace.c
> index 59451c1..73727ce 100644
> --- a/ipc/namespace.c
> +++ b/ipc/namespace.c
> @@ -13,6 +13,7 @@
> #include <linux/mount.h>
> #include <linux/user_namespace.h>
> #include <linux/proc_ns.h>
> +#include <linux/audit.h>
>
> #include "util.h"
>
> @@ -41,6 +42,8 @@ static struct ipc_namespace *create_ipc_ns(struct
> user_namespace *user_ns, }
> atomic_inc(&nr_ipc_ns);
>
> + audit_log_ns_init(AUDIT_NS_INIT_IPC, old_ns->proc_inum, ns->proc_inum);
> +
> sem_init_ns(ns);
> msg_init_ns(ns);
> shm_init_ns(ns);
> @@ -119,6 +122,7 @@ static void free_ipc_ns(struct ipc_namespace *ns)
> */
> ipcns_notify(IPCNS_REMOVED);
> put_user_ns(ns->user_ns);
> + audit_log_ns_del(AUDIT_NS_DEL_IPC, ns->proc_inum);
> proc_free_inum(ns->proc_inum);
> kfree(ns);
> }
> @@ -197,3 +201,11 @@ const struct proc_ns_operations ipcns_operations = {
> .install = ipcns_install,
> .inum = ipcns_inum,
> };
> +
> +/* log the ID of init IPC namespace after audit service starts */
> +static int __init ipc_namespaces_init(void)
> +{
> + audit_log_ns_init(AUDIT_NS_INIT_IPC, 0, init_ipc_ns.proc_inum);
> + return 0;
> +}
> +late_initcall(ipc_namespaces_init);
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 63f32f4..e6230c4 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1978,6 +1978,70 @@ out:
> kfree(name);
> }
>
> +#ifdef CONFIG_NAMESPACES
> +static char *ns_name[] = {
> + "mnt",
> + "uts",
> + "ipc",
> + "user",
> + "pid",
> + "net",
> +};
> +
> +/**
> + * audit_log_ns_init - report a namespace instance creation
> + * @type: type of audit namespace instance created message
> + * @old_inum: the ID number of the cloned namespace instance
> + * @inum: the ID number of the new namespace instance
> + */
> +void audit_log_ns_init(int type, unsigned int old_inum, unsigned int inum)
> +{
> + struct audit_buffer *ab;
> + char *audit_ns_name = ns_name[type - AUDIT_NS_INIT_MNT];
> + struct vfsmount *mnt = task_active_pid_ns(current)->proc_mnt;
> + struct super_block *sb = mnt->mnt_sb;
> + char old_ns[16];
> +
> + if (type < AUDIT_NS_INIT_MNT || type > AUDIT_NS_INIT_NET) {
> + WARN(1, "audit_log_ns_init: type:%d out of range", type);
> + return;
> + }
> + if (!old_inum)
> + sprintf(old_ns, "(none)");
> + else
> + sprintf(old_ns, "%d", old_inum - PROC_DYNAMIC_FIRST);
> + audit_log_common_recv_msg(&ab, type);
> + audit_log_format(ab, " dev=%02x:%02x old_%sns=%s %sns=%d res=1",
> + MAJOR(sb->s_dev), MINOR(sb->s_dev),
> + audit_ns_name, old_ns,
> + audit_ns_name, inum - PROC_DYNAMIC_FIRST);
> + audit_log_end(ab);
> +}
> +
> +/**
> + * audit_log_ns_del - report a namespace instance deleted
> + * @type: type of audit namespace instance deleted message
> + * @inum: the ID number of the namespace instance
> + */
> +void audit_log_ns_del(int type, unsigned int inum)
> +{
> + struct audit_buffer *ab;
> + char *audit_ns_name = ns_name[type - AUDIT_NS_DEL_MNT];
> + struct vfsmount *mnt = task_active_pid_ns(current)->proc_mnt;
> + struct super_block *sb = mnt->mnt_sb;
> +
> + if (type < AUDIT_NS_DEL_MNT || type > AUDIT_NS_DEL_NET) {
> + WARN(1, "audit_log_ns_del: type:%d out of range", type);
> + return;
> + }
> + audit_log_common_recv_msg(&ab, type);
> + audit_log_format(ab, " dev=%02x:%02x %sns=%d res=1",
> + MAJOR(sb->s_dev), MINOR(sb->s_dev), audit_ns_name,
> + inum - PROC_DYNAMIC_FIRST);
> + audit_log_end(ab);
> +}
> +#endif /* CONFIG_NAMESPACES */
> +
> /**
> * audit_log_end - end one audit record
> * @ab: the audit_buffer
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index db95d8e..d28fd14 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -18,6 +18,7 @@
> #include <linux/proc_ns.h>
> #include <linux/reboot.h>
> #include <linux/export.h>
> +#include <linux/audit.h>
>
> struct pid_cache {
> int nr_ids;
> @@ -109,6 +110,9 @@ static struct pid_namespace *create_pid_namespace(struct
> user_namespace *user_ns if (err)
> goto out_free_map;
>
> + audit_log_ns_init(AUDIT_NS_INIT_PID, parent_pid_ns->proc_inum,
> + ns->proc_inum);
> +
> kref_init(&ns->kref);
> ns->level = level;
> ns->parent = get_pid_ns(parent_pid_ns);
> @@ -142,6 +146,7 @@ static void destroy_pid_namespace(struct pid_namespace
> *ns) {
> int i;
>
> + audit_log_ns_del(AUDIT_NS_DEL_PID, ns->proc_inum);
> proc_free_inum(ns->proc_inum);
> for (i = 0; i < PIDMAP_ENTRIES; i++)
> kfree(ns->pidmap[i].page);
> @@ -388,3 +393,11 @@ static __init int pid_namespaces_init(void)
> }
>
> __initcall(pid_namespaces_init);
> +
> +/* log the ID of init PID namespace after audit service starts */
> +static __init int pid_namespaces_late_init(void)
> +{
> + audit_log_ns_init(AUDIT_NS_INIT_PID, 0, init_pid_ns.proc_inum);
> + return 0;
> +}
> +late_initcall(pid_namespaces_late_init);
> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
> index fcc0256..89c2517 100644
> --- a/kernel/user_namespace.c
> +++ b/kernel/user_namespace.c
> @@ -22,6 +22,7 @@
> #include <linux/ctype.h>
> #include <linux/projid.h>
> #include <linux/fs_struct.h>
> +#include <linux/audit.h>
>
> static struct kmem_cache *user_ns_cachep __read_mostly;
>
> @@ -92,6 +93,9 @@ int create_user_ns(struct cred *new)
> return ret;
> }
>
> + audit_log_ns_init(AUDIT_NS_INIT_USER, parent_ns->proc_inum,
> + ns->proc_inum);
> +
> atomic_set(&ns->count, 1);
> /* Leave the new->user_ns reference with the new user namespace. */
> ns->parent = parent_ns;
> @@ -136,6 +140,7 @@ void free_user_ns(struct user_namespace *ns)
> #ifdef CONFIG_PERSISTENT_KEYRINGS
> key_put(ns->persistent_keyring_register);
> #endif
> + audit_log_ns_del(AUDIT_NS_DEL_USER, ns->proc_inum);
> proc_free_inum(ns->proc_inum);
> kmem_cache_free(user_ns_cachep, ns);
> ns = parent;
> @@ -909,3 +914,11 @@ static __init int user_namespaces_init(void)
> return 0;
> }
> subsys_initcall(user_namespaces_init);
> +
> +/* log the ID of init user namespace after audit service starts */
> +static __init int user_namespaces_late_init(void)
> +{
> + audit_log_ns_init(AUDIT_NS_INIT_USER, 0, init_user_ns.proc_inum);
> + return 0;
> +}
> +late_initcall(user_namespaces_late_init);
> diff --git a/kernel/utsname.c b/kernel/utsname.c
> index fd39312..fa21e8d 100644
> --- a/kernel/utsname.c
> +++ b/kernel/utsname.c
> @@ -16,6 +16,7 @@
> #include <linux/slab.h>
> #include <linux/user_namespace.h>
> #include <linux/proc_ns.h>
> +#include <linux/audit.h>
>
> static struct uts_namespace *create_uts_ns(void)
> {
> @@ -48,6 +49,8 @@ static struct uts_namespace *clone_uts_ns(struct
> user_namespace *user_ns, return ERR_PTR(err);
> }
>
> + audit_log_ns_init(AUDIT_NS_INIT_UTS, old_ns->proc_inum, ns->proc_inum);
> +
> down_read(&uts_sem);
> memcpy(&ns->name, &old_ns->name, sizeof(ns->name));
> ns->user_ns = get_user_ns(user_ns);
> @@ -84,6 +87,7 @@ void free_uts_ns(struct kref *kref)
>
> ns = container_of(kref, struct uts_namespace, kref);
> put_user_ns(ns->user_ns);
> + audit_log_ns_del(AUDIT_NS_DEL_UTS, ns->proc_inum);
> proc_free_inum(ns->proc_inum);
> kfree(ns);
> }
> @@ -138,3 +142,11 @@ const struct proc_ns_operations utsns_operations = {
> .install = utsns_install,
> .inum = utsns_inum,
> };
> +
> +/* log the ID of init UTS namespace after audit service starts */
> +static int __init uts_namespaces_init(void)
> +{
> + audit_log_ns_init(AUDIT_NS_INIT_UTS, 0, init_uts_ns.proc_inum);
> + return 0;
> +}
> +late_initcall(uts_namespaces_init);
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 85b6269..562eb85 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -17,6 +17,7 @@
> #include <linux/user_namespace.h>
> #include <net/net_namespace.h>
> #include <net/netns/generic.h>
> +#include <linux/audit.h>
>
> /*
> * Our network namespace constructor/destructor lists
> @@ -253,6 +254,8 @@ struct net *copy_net_ns(unsigned long flags,
> mutex_lock(&net_mutex);
> rv = setup_net(net, user_ns);
> if (rv == 0) {
> + audit_log_ns_init(AUDIT_NS_INIT_NET, old_net->proc_inum,
> + net->proc_inum);
> rtnl_lock();
> list_add_tail_rcu(&net->list, &net_namespace_list);
> rtnl_unlock();
> @@ -389,6 +392,7 @@ static __net_init int net_ns_net_init(struct net *net)
>
> static __net_exit void net_ns_net_exit(struct net *net)
> {
> + audit_log_ns_del(AUDIT_NS_DEL_NET, net->proc_inum);
> proc_free_inum(net->proc_inum);
> }
>
> @@ -435,6 +439,14 @@ static int __init net_ns_init(void)
>
> pure_initcall(net_ns_init);
>
> +/* log the ID of init_net namespace after audit service starts */
> +static int __init net_ns_init_log(void)
> +{
> + audit_log_ns_init(AUDIT_NS_INIT_NET, 0, init_net.proc_inum);
> + return 0;
> +}
> +late_initcall(net_ns_init_log);
> +
> #ifdef CONFIG_NET_NS
> static int __register_pernet_operations(struct list_head *list,
> struct pernet_operations *ops)
^ permalink raw reply
* Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings
From: Daniel Thompson @ 2015-05-05 14:07 UTC (permalink / raw)
To: Maxime Coquelin, Philipp Zabel
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Linus Walleij, Arnd Bergmann, Stefan Agner,
Peter Meerwald, Paul Bolle, Peter Hurley, Andy Shevchenko,
Chanwoo Choi, Russell King, Daniel Lezcano, Joe Perches,
Vladimir Zapolskiy, Jonathan Corbet, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Thomas Gleixner
In-Reply-To: <CALszF6BTb0Ce6jfT5gY4eEtSep6+8XqOxu1LbpUXHmPYX9PmgQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 04/05/15 12:25, Maxime Coquelin wrote:
> 2015-05-02 12:01 GMT+02:00 Daniel Thompson <daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>> On 02/05/15 08:55, Maxime Coquelin wrote:
>>>
>>> 2015-05-01 10:08 GMT+02:00 Daniel Thompson <daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>>>>
>>>> On 30/04/15 17:20, Maxime Coquelin wrote:
>>>>>
>>>>>
>>>>> This adds documentation of device tree bindings for the
>>>>> STM32 reset controller.
>>>>>
>>>>> Tested-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>>> Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> ---
>>>>> .../devicetree/bindings/reset/st,stm32-rcc.txt | 107
>>>>> +++++++++++++++++++++
>>>>> 1 file changed, 107 insertions(+)
>>>>> create mode 100644
>>>>> Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>> b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>> new file mode 100644
>>>>> index 0000000..c1b0f8d
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>>>> @@ -0,0 +1,107 @@
>>>>> +STMicroelectronics STM32 Peripheral Reset Controller
>>>>> +====================================================
>>>>> +
>>>>> +The RCC IP is both a reset and a clock controller. This documentation
>>>>> only
>>>>> +documents the reset part.
>>>>> +
>>>>> +Please also refer to reset.txt in this directory for common reset
>>>>> +controller binding usage.
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible: Should be "st,stm32-rcc"
>>>>> +- reg: should be register base and length as documented in the
>>>>> + datasheet
>>>>> +- #reset-cells: 1, see below
>>>>> +
>>>>> +example:
>>>>> +
>>>>> +rcc: reset@40023800 {
>>>>> + #reset-cells = <1>;
>>>>> + compatible = "st,stm32-rcc";
>>>>
>>>>
>>>>
>>>> Do you intend the clock driver to use the same compatible string (given
>>>> it
>>>> is the same bit of hardware).
>>>>
>>>> If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me
>>>> that
>>>> the register layout of the PLLs and dividers can be the same on the f7
>>>> parts
>>>> (and later).
>>>
>>>
>>> I agree we need a compatible dedicate to f4 series for clocks, and
>>> maybe even one for f429 (to be checked).
>>> For the reset part, we don't have this need.
>>>
>>> So either we use only "st,stm32f4" as you suggest, or we can have both
>>> in device tree:
>>>
>>> rcc: reset@40023800 {
>>> #reset-cells = <1>;
>>> compatible = "st,stm32f4-rcc", "st,stm32-rcc";
>>> reg = <0x40023800 0x400>;
>>> };
>>>
>>> What do you think?
>>
>>
>> Having both makes sense. The reset driver probably doesn't care about
>> differences between F4 and F7 (I know very little about F7 but I can't think
>> of any obvious h/ware evolution that would confuse the current reset
>> driver).
>>
>>
>>>>> + reg = <0x40023800 0x400>;
>>>>> +};
>>>>> +
>>>>> +Specifying softreset control of devices
>>>>> +=======================================
>>>>> +
>>>>> +Device nodes should specify the reset channel required in their
>>>>> "resets"
>>>>> +property, containing a phandle to the reset device node and an index
>>>>> specifying
>>>>> +which channel to use.
>>>>> +The index is the bit number within the RCC registers bank, starting
>>>>> from
>>>>> RCC
>>>>> +base address.
>>>>> +It is calculated as: index = register_offset / 4 * 32 + bit_offset.
>>>>> +Where bit_offset is the bit offset within the register.
>>>>> +For example, for CRC reset:
>>>>> + crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 +
>>>>> 12
>>>>> = 140
>>>>> +
>>>>> +example:
>>>>> +
>>>>> + timer2 {
>>>>> + resets = <&rcc 256>;
>>>>> + };
>>>>> +
>>>>> +List of valid indices for STM32F429:
>>>>> + - gpioa: 128
>>>>> + - gpiob: 129
>>>>> ...
>>>>> <snip>
>>>>> ...
>>>>> + - sai1: 310
>>>>> + - ltdc: 314
>>>>
>>>>
>>>>
>>>> These numbers are stable for all STM32F4 family parts. Should this table
>>>> go
>>>> into a dt-bindings header file?
>>>>
>>>
>>> This has already been discussed with Philipp and Arnd in earlier
>>> versions of this series [0].
>>> I initially created a header file, and we decided going this way finally.
>>
>>
>> Thanks for the link. I had overlooked that (I only really started paying
>> attention at v5; I should probably have looked further back before
>> commenting).
>>
>> However...
>>
>> Arnd's concerns about mergability of headers can also be met by using h/ware
>> values in the header file can't there. To be honest my comment was pretty
>> heavily influenced after having read a recent patch from Rob Herring (
>> https://lkml.org/lkml/2015/5/1/14 ) which does exactly this.
>>
>> The main reason I got interested in having a header is that the reset bits
>> and the clock gate bits are encoded using the same bit patterns so I
>> wondering it we could express that only once.
>
> Ok, I understand your need, and it makes sense.
> The problem is that the values defined today cannot be re-used
> directly for clocks.
> Since the calculation is starting from rcc base, there is a 128 offset.
>
> To re-use the same values, maybe we should create a mfd dt-binding header file.
> It would contain the bits definition starting from 0, and define
> macros for both reset and clocks to add the offsets.
>
> For example, includes/dt-bindings/mfd/stm32f4-rcc.h would look like:
>
> #define GPIOA 0
> #define GPIOB 1
> ...
> #define LTDC 186
>
> #define STM32F4_RESET(x) (x + 128)
> #define STM32F4_CLOCK(x) (x + 384)
>
> Then, in DT, a reset would be described like this:
>
> timer2 {
> resets = <&rcc STM32F4_RESET(TIM2)>;
> };
>
> Phillip, Daniel, does that look acceptable to you?
Doesn't look unreasonable.
I am a little uneasy simply because there are very few similar header
files in that directory but I haven't thought of a better idea.
Daniel.
>
> Kind regards,
> Maxime
>>
>> I guess it doesn't matter that much, especially given there is only one
>> .dtsi file, and we can add a header later and remain binary compatible.
>> However if the same number set does end up repeated in different .dtsi files
>> I think that would motivate adding a header for F4 family.
>>
>>
>> Daniel.
>>
^ permalink raw reply
* Re: [RFC PATCH 1/3] iio: export mounting matrix information
From: Jonathan Cameron @ 2015-05-05 13:55 UTC (permalink / raw)
To: Octavian Purdila
Cc: Lars-Peter Clausen, Peter Meerwald, Robert Moore,
Rafael J Wysocki, Len Brown, linux-api-u79uwXL29TY76Z2rM5mHXA,
lkml, linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAE1zot+X5RV7iexE4dUPY_YBGP4Zet1S1hSmauP8-e5P59nXRQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 4 May 2015 18:48:23 GMT+01:00, Octavian Purdila <octavian.purdila-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>On Mon, May 4, 2015 at 2:25 PM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>wrote:
>> On 27/04/15 16:01, Octavian Purdila wrote:
>>> Export a new sysfs attribute that describes the placement of the
>>> sensor on the device in the form of a mounting matrix so that
>>> userspace can do the required correction to get accurate data:
>>>
>>> corrected X = MM[0] * X + MM[1] Y + MM[2] * Z
>>> corrected Y = MM[3] * X + MM[4] Y + MM[5] * Z
>>> corrected Z = MM[6] * X + MM[7] Y + MM[8] * Z
>>>
>>> This information is read from the device properties of the parent of
>>> the IIO device.
>>>
>>> Signed-off-by: Octavian Purdila <octavian.purdila-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Hmm. This could be done with existing code and a new info_mask
>element.
>> The disadvantage is you'd have to change the read_raw to
>read_raw_multi
>> callback, but that's hardly a big job. If I could be bothered, I'd
>> move the whole subsystem over and drop read_raw entirely.
>>
>> It was introduced precisely for this sort of element.
>
>If I understand this correctly this will require changing every driver
>that want to expose this information. However, this information is
>independent of the driver, as this information is read from the device
>tree or ACPI. As such, doesn't this fits better in the IIO core?
In this case it comes from one of those two but there is no inherent reason it won't come from elsewhere.
Take for example an IMU block with integrated components. The mounting
matrix is then partly provided by acpi say and partly by values read from the device.
Yes moving to read_raw_multi involves a driver change but that is no bad thing anyway and the change is fairly trivial.
>
>> As I mentioned deeper in the thread. If we are going to introduce a
>mounting
>> matrix, I'd prefer a version that includes translation. It might not
>matter
>> to many devices but it has mattered a lot to me in the past and
>doesn't hurt
>> others that much (I used to write papers on how to estimate this
>stuff
>> from black box devices).
>
>OK, I will look into that.
>
>
>>> ---
>>> Documentation/ABI/testing/sysfs-bus-iio | 11 +++++++++
>>> drivers/iio/industrialio-core.c | 42
>+++++++++++++++++++++++++++++++++
>>> include/linux/iio/iio.h | 9 +++++++
>>> 3 files changed, 62 insertions(+)
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
>b/Documentation/ABI/testing/sysfs-bus-iio
>>> index 866b4ec..d36476e 100644
>>> --- a/Documentation/ABI/testing/sysfs-bus-iio
>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio
>>> @@ -1375,3 +1375,14 @@ Description:
>>> The emissivity ratio of the surface in the field of
>view of the
>>> contactless temperature sensor. Emissivity varies
>from 0 to 1,
>>> with 1 being the emissivity of a black body.
>>> +
>>> +What:
>/sys/bus/iio/devices/iio:deviceX/mounting_matrix
>>> +KernelVersion: 4.2
>>> +Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> +Description:
>>> + A list of 9 floating point values that describes the
>>> + transformation needed to account for the way the
>sensor has been
>>> + placed on the PCB:
>>> + corrected X = MM[0] * X + MM[1] Y + MM[2] * Z
>>> + corrected Y = MM[3] * X + MM[4] Y + MM[5] * Z
>>> + corrected Z = MM[6] * X + MM[7] Y + MM[8] * Z
>>> diff --git a/drivers/iio/industrialio-core.c
>b/drivers/iio/industrialio-core.c
>>> index 7c98bc1..9000c53 100644
>>> --- a/drivers/iio/industrialio-core.c
>>> +++ b/drivers/iio/industrialio-core.c
>>> @@ -871,6 +871,45 @@ static ssize_t iio_show_dev_name(struct device
>*dev,
>>>
>>> static DEVICE_ATTR(name, S_IRUGO, iio_show_dev_name, NULL);
>>>
>>> +static bool iio_get_mounting_matrix(struct iio_dev *indio_dev)
>>> +{
>>> + int i, err;
>>> +
>>> + err = device_property_read_u32_array(&indio_dev->dev,
>"mounting-matrix",
>>> +
>indio_dev->mounting_matrix, 9);
>>> + if (!err) {
>>> + int *mm = indio_dev->mounting_matrix;
>>> +
>>> + for (i = IIO_MM_SIZE - 2; i > 0; i -= 2) {
>>> + mm[i] = mm[i / 2];
>>> + mm[i + 1] = 0;
>>> + }
>>> +
>>> + return true;
>>> + }
>>> +
>>> + return false;
>>> +}
>>> +
>>> +static ssize_t iio_show_mounting_matrix(struct device *dev,
>>> + struct device_attribute *attr,
>>> + char *buf)
>>> +{
>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>> + char *tmp = buf;
>>> + int i;
>>> +
>>> + for (i = 0; i < IIO_MM_SIZE; i += 2) {
>>> + tmp += iio_format_value(tmp, IIO_VAL_INT_PLUS_MICRO,
>2,
>>> +
>&indio_dev->mounting_matrix[i]);
>>> + if (((i + 2) / 2) % 3)
>> Hmm. if (i != 8) should also do the job with slightly less feedling
>of
>> magic..
>>> + tmp[-1] = ' ';
>>> + }
>>> + return tmp - buf;
>>> +}
>>> +
>>> +static DEVICE_ATTR(mounting_matrix, S_IRUGO,
>iio_show_mounting_matrix, NULL);
>>> +
>>> static int iio_device_register_sysfs(struct iio_dev *indio_dev)
>>> {
>>> int i, ret = 0, attrcount, attrn, attrcount_orig = 0;
>>> @@ -920,6 +959,9 @@ static int iio_device_register_sysfs(struct
>iio_dev *indio_dev)
>>> indio_dev->chan_attr_group.attrs[attrn++] =
>&p->dev_attr.attr;
>>> if (indio_dev->name)
>>> indio_dev->chan_attr_group.attrs[attrn++] =
>&dev_attr_name.attr;
>>> + if (iio_get_mounting_matrix(indio_dev))
>>> + indio_dev->chan_attr_group.attrs[attrn++] =
>>> + &dev_attr_mounting_matrix.attr;
>>>
>>> indio_dev->groups[indio_dev->groupcounter++] =
>>> &indio_dev->chan_attr_group;
>>> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
>>> index b1e46ae..c1fa852 100644
>>> --- a/include/linux/iio/iio.h
>>> +++ b/include/linux/iio/iio.h
>>> @@ -434,6 +434,8 @@ struct iio_buffer_setup_ops {
>>> const unsigned long *scan_mask);
>>> };
>>>
>>> +#define IIO_MM_SIZE 18
>>> +
>>> /**
>>> * struct iio_dev - industrial I/O device
>>> * @id: [INTERN] used to identify device
>internally
>>> @@ -469,6 +471,12 @@ struct iio_buffer_setup_ops {
>>> * @groups: [INTERN] attribute groups
>>> * @groupcounter: [INTERN] index of next attribute group
>>> * @flags: [INTERN] file ops related flags including busy
>flag.
>> Hmm. No absolute need to have this new data in the iio_dev. I'd do
>it
>> via the read_raw_multi callback, though this will require converting
>read_raw
>> over to that more flexible version.
>>> + * @mounting_matrix: [INTERN] the mounting matrix is a series of 9
>>> + * IIO_VAL_INT_PLUS_MICRO pairs that describes
>the
>>> + * transformation needed to account for the way
>the sensor
>>> + * has been placed on the PCB. See the
>mounting_matrix
>>> + * entry in
>Documentation/ABI/testing/sysfs-bus-iio about
>>> + * details of the transformation operations.
>>> * @debugfs_dentry: [INTERN] device specific debugfs dentry.
>>> * @cached_reg_addr: [INTERN] cached register address for debugfs
>reads.
>>> */
>>> @@ -509,6 +517,7 @@ struct iio_dev {
>>> int groupcounter;
>>>
>>> unsigned long flags;
>>> + int mounting_matrix[IIO_MM_SIZE];
>>> #if defined(CONFIG_DEBUG_FS)
>>> struct dentry *debugfs_dentry;
>>> unsigned cached_reg_addr;
>>>
>>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [RFC v2 1/4] fs: Add generic file system event notifications
From: Beata Michalska @ 2015-05-05 12:16 UTC (permalink / raw)
To: Greg KH
Cc: Jan Kara, linux-kernel, linux-fsdevel, linux-api, tytso,
adilger.kernel, hughd, lczerner, hch, linux-ext4, linux-mm,
kyungmin.park, kmpark
In-Reply-To: <20150429091303.GA4090@kroah.com>
Hi again,
On 04/29/2015 11:13 AM, Greg KH wrote:
> On Wed, Apr 29, 2015 at 09:42:59AM +0200, Jan Kara wrote:
>> On Wed 29-04-15 09:03:08, Beata Michalska wrote:
>>> On 04/28/2015 07:39 PM, Greg KH wrote:
>>>> On Tue, Apr 28, 2015 at 04:46:46PM +0200, Beata Michalska wrote:
>>>>> On 04/28/2015 04:09 PM, Greg KH wrote:
>>>>>> On Tue, Apr 28, 2015 at 03:56:53PM +0200, Jan Kara wrote:
>>>>>>> On Mon 27-04-15 17:37:11, Greg KH wrote:
>>>>>>>> On Mon, Apr 27, 2015 at 05:08:27PM +0200, Beata Michalska wrote:
>>>>>>>>> On 04/27/2015 04:24 PM, Greg KH wrote:
>>>>>>>>>> On Mon, Apr 27, 2015 at 01:51:41PM +0200, Beata Michalska wrote:
>>>>>>>>>>> Introduce configurable generic interface for file
>>>>>>>>>>> system-wide event notifications, to provide file
>>>>>>>>>>> systems with a common way of reporting any potential
>>>>>>>>>>> issues as they emerge.
>>>>>>>>>>>
>>>>>>>>>>> The notifications are to be issued through generic
>>>>>>>>>>> netlink interface by newly introduced multicast group.
>>>>>>>>>>>
>>>>>>>>>>> Threshold notifications have been included, allowing
>>>>>>>>>>> triggering an event whenever the amount of free space drops
>>>>>>>>>>> below a certain level - or levels to be more precise as two
>>>>>>>>>>> of them are being supported: the lower and the upper range.
>>>>>>>>>>> The notifications work both ways: once the threshold level
>>>>>>>>>>> has been reached, an event shall be generated whenever
>>>>>>>>>>> the number of available blocks goes up again re-activating
>>>>>>>>>>> the threshold.
>>>>>>>>>>>
>>>>>>>>>>> The interface has been exposed through a vfs. Once mounted,
>>>>>>>>>>> it serves as an entry point for the set-up where one can
>>>>>>>>>>> register for particular file system events.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Beata Michalska <b.michalska@samsung.com>
>>>>>>>>>>> ---
>>>>>>>>>>> Documentation/filesystems/events.txt | 231 ++++++++++
>>>>>>>>>>> fs/Makefile | 1 +
>>>>>>>>>>> fs/events/Makefile | 6 +
>>>>>>>>>>> fs/events/fs_event.c | 770 ++++++++++++++++++++++++++++++++++
>>>>>>>>>>> fs/events/fs_event.h | 25 ++
>>>>>>>>>>> fs/events/fs_event_netlink.c | 99 +++++
>>>>>>>>>>> fs/namespace.c | 1 +
>>>>>>>>>>> include/linux/fs.h | 6 +-
>>>>>>>>>>> include/linux/fs_event.h | 58 +++
>>>>>>>>>>> include/uapi/linux/fs_event.h | 54 +++
>>>>>>>>>>> include/uapi/linux/genetlink.h | 1 +
>>>>>>>>>>> net/netlink/genetlink.c | 7 +-
>>>>>>>>>>> 12 files changed, 1257 insertions(+), 2 deletions(-)
>>>>>>>>>>> create mode 100644 Documentation/filesystems/events.txt
>>>>>>>>>>> create mode 100644 fs/events/Makefile
>>>>>>>>>>> create mode 100644 fs/events/fs_event.c
>>>>>>>>>>> create mode 100644 fs/events/fs_event.h
>>>>>>>>>>> create mode 100644 fs/events/fs_event_netlink.c
>>>>>>>>>>> create mode 100644 include/linux/fs_event.h
>>>>>>>>>>> create mode 100644 include/uapi/linux/fs_event.h
>>>>>>>>>>
>>>>>>>>>> Any reason why you just don't do uevents for the block devices today,
>>>>>>>>>> and not create a new type of netlink message and userspace tool required
>>>>>>>>>> to read these?
>>>>>>>>>
>>>>>>>>> The idea here is to have support for filesystems with no backing device as well.
>>>>>>>>> Parsing the message with libnl is really simple and requires few lines of code
>>>>>>>>> (sample application has been presented in the initial version of this RFC)
>>>>>>>>
>>>>>>>> I'm not saying it's not "simple" to parse, just that now you are doing
>>>>>>>> something that requires a different tool. If you have a block device,
>>>>>>>> you should be able to emit uevents for it, you don't need a backing
>>>>>>>> device, we handle virtual filesystems in /sys/block/ just fine :)
>>>>>>>>
>>>>>>>> People already have tools that listen to libudev for system monitoring
>>>>>>>> and management, why require them to hook up to yet-another-library? And
>>>>>>>> what is going to provide the ability for multiple userspace tools to
>>>>>>>> listen to these netlink messages in case you have more than one program
>>>>>>>> that wants to watch for these things (i.e. multiple desktop filesystem
>>>>>>>> monitoring tools, system-health checkers, etc.)?
>>>>>>> As much as I understand your concerns I'm not convinced uevent interface
>>>>>>> is a good fit. There are filesystems that don't have underlying block
>>>>>>> device - think of e.g. tmpfs or filesystems working directly on top of
>>>>>>> flash devices. These still want to send notification to userspace (one of
>>>>>>> primary motivation for this interfaces was so that tmpfs can notify about
>>>>>>> something). And creating some fake nodes in /sys/block for tmpfs and
>>>>>>> similar filesystems seems like doing more harm than good to me...
>>>>>>
>>>>>> If these are "fake" block devices, what's going to be present in the
>>>>>> block major/minor fields of the netlink message? For some reason I
>>>>>> thought it was a required field, and because of that, I thought we had a
>>>>>> "real" filesystem somewhere to refer to, otherwise how would userspace
>>>>>> know what filesystem was creating these events?
>>>>>>
>>>>>> What am I missing here?
>>>>>>
>>>>>> confused,
>>>>>>
>>>>>> greg k-h
>>>>>>
>>>>>
>>>>> For those 'fake' block devs, upon mount, get_anon_bdev will assign
>>>>> the major:minor numbers. Userspace might get those through stat.
>>>>
>>>> How can userspace do the mapping backwards from this "anonymous"
>>>> major:minor number for these types of filesystems in such a way that
>>>> they can "know" how to report the block device that is causing the
>>>> event?
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>>
>>>
>>> It needs to be done internally by the app but is doable.
>>> The app knows what it is watching, so it can maintain the mappings.
>>> So prior to activating the notifications it can call 'stat' on the mount point.
>>> Stat struct gives the 'st_dev' which is the device id. Same will be reported
>>> within the message payload (through major:minor numbers). So having this,
>>> the app is able to get any other information it needs.
>>> Note that the events refer to the file system as a whole and they may not
>>> necessarily have anything to do with the actual block device.
>
> How are you going to show an event for a filesystem that is made up of
> multiple block devices?
>
>> Or you can use /proc/self/mountinfo for the mapping. There you can see
>> device numbers, real device names if applicable and mountpoints. This has
>> the advantage that it works even if filesystem mountpoints change.
>
> Ok, then that brings up my next question, how does this handle
> namespaces? What namespace is the event being sent in? block devices
> aren't namespaced, but the mount points are, is that going to cause
> problems?
>
> thanks,
>
> greg k-h
>
Getting back to the namespaces ...
In the current state the notifications will be sent to the init network namespace,
which means that processes belonging to a different net namespace will not
be able to receive them. To be more precise, those processes will not be
able to subscribe to the multicast group, though this can be easily changed.
Furthermore, the notifications might also be sent to specific namespace.
In this case, the one, with which the trace for the mount point has been registered,
which as I believe would be the best approach.
As for the mount namespaces, reading the config file needs to be slightly tweaked,
to hide away all the registered mount points which does not belong to the current
mount namespace.
Still, there is one possible 'issue' - the private/slave mount points.
As the notifications will be sent to all the listeners (within the same netns),
the events might be visible to processes outside the given mount ns.
This should be limited to only those listeners that share the mount namespace,
to which such private/slave mount points belong. As using the generic netlink
to filter the outgoing messages is doable (with small changes to current
implementation), the filters themselves seem rather cumbersome, as they would require
finding the socket’s owner mount namespace, which just doesn't seems right.
On the other hand, identifying the file system, which generated the event, will
not be possible for processes outside such namespace, as device major:minor
numbers are not bound to any namespace (afaict) so they will not provide any
valid information. They will remain unresolved.
The best way out here though, is to leave it to userspace to properly setup new namespaces:
the mount namespace with possible private/slave mounts should have a separate
network namespace to isolate the potential fs events, if required.
BR
Beata
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4 04/10] eeprom: Add a simple EEPROM framework for eeprom consumers
From: Srinivas Kandagatla @ 2015-05-05 11:46 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Rob Herring, Kumar Gala, Mark Brown,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ, Greg Kroah-Hartman,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, arnd-r2nGTMty4D4
In-Reply-To: <20150409144522.GB9663-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Hi Stephen,
Sorry I took so long to reply.
On 09/04/15 15:45, Stephen Boyd wrote:
> On 04/07, Srinivas Kandagatla wrote:
>> On 07/04/15 19:45, Stephen Boyd wrote:
>>> On 03/30, Srinivas Kandagatla wrote:
>>>
>>> Do you have an overview of how to use these APIs? Maybe some
>>> Documentation/ is in order? I'm mostly interested in how the
>>> blocks array is supposed to work and how this hooks up to drivers
>>> that are using DT.
>>
>> Only doc ATM is function level kernel doc in c file.
>> May be I can explain you for now and I will try to add some
>> documentation with some usage examples in next version.
>
> Thanks.
>
>>
>> eeprom block array is just another way intended to get hold of
>> eeprom content for non-DT providers/consumers, but DT
>> consumers/providers can also use it. As of today SOC/mach level code
>> could use it as well.
>>
>> In eeprom_cell_get() case the lookup of provider is done based on
>> provider name, this provider name is generally supplied by all the
>> providers (both DT/non DT).
>>
>> for example in qfprom case,
>> provider is registered from DT with eeprom config containing a unique name:
>> static struct eeprom_config econfig = {
>> .name = "qfprom",
>> .id = 0,
>> };
>>
>> In the consumer case, the tsens driver could do some like in non DT way:
>>
>> struct eeprom_block blocks[4] ={
>> {
>> .offset = 0x404,
>> .count = 0x4,
>> },
>> {
>> .offset = 0x408,
>> .count = 0x4,
>> },
>> {
>> .offset = 0x40c,
>> .count = 0x4,
>> },
>> {
>> .offset = 0x410,
>> .count = 0x4,
>> },
>> };
>> calib_cell = eeprom_cell_get("qfprom0", blocks, 4);
>>
>>
>> Or in DT way
>> calib_cell = of_eeprom_cell_get(np, "calib");
>>
>
> Ok. I guess I was hoping for a more device centric approach like
> we have for clks/regulators/etc. That way a driver doesn't need
> to know it's using DT or not to figure out which API to call.
That would be the best. Its easy to wrap up whats in eeprom core to
eeprom_get_cell(dev, "cell-name") for both DT and non-dt cases, if I
remove the nasty global name space thing.
Only thing which is limiting it is the existing bindings which are just
phandle based. For eeprom to be more of device centric we need more
generic bindings/property names like
nvrom-cell = <&abc>, <&edf>
nvrom-cell-names = "cell1", "cell2";
Also we can have name associated to each eeprom cell which would help
for non-dt cases. So they can just lookup by the cell name.
Sacha, Are you ok with such binding? As this can provide a single
interface for dt and non-dt. I remember you requested for changing from
generic properties to specific property names.
> Also the global namespace is sort of worrying (qfprom0 part). How
> do we know it's qfprom0? What if it's qfprom1 sometimes?
I agree this is something which I don't like it in the first place too.
If we have something like names associated to each eeprom cell like clks
or regulators we can have some thing like eeprom_get_cell(dev, name);
>
> Also, how are we supposed to encode certain bits inside the
> stream of bytes (blocks)? In some situations (e.g. the qcom CPR
> stuff) we have quite a few fuse bits we need to read that are
> packed into different bytes and may cross byte boundaries (i.e.
> bits 6 to 10 of a 32-bit word). The current API looks to be byte
> focused when I have bit based/non-byte aligned data.
Yes, it is more of byte oriented. However we can add some new apis for
parsers like ones you are working on.
of_eeprom_get_provider_regmap(phandle) just to get handle to regmap from
eeprom_core, which would provide most of the apis you would need.
Am guessing eeprom parsers would need need such interface to eeprom-core
in future anyway.
>
> My current feeling is that I don't want to use any of the block
> stuff at all. I just want a simple byte-based API that allows me
> to read a number of contiguous bytes from the fuses. Then I'll
> need to shift that data down by a few bits and mask it with the
> width of the data I want to read to extract the data needed.
>
> The only thing after that where I have a problem is figuring out
> which eeprom is present in the consumer driver. I think I may
> need to open-code it and look at the phandle for the eeprom and
> do a compatible check to figure out which bits I want to read.
>
> The DT would be like this (note I left eeprom-cells/eeproms here
> because that allows us to generically find eeproms used by a
> device and find eeprom providers):
I though, having "eeprom-cells" would be make sense only if the bindings
have possible arguments to a phandle. In this case it would be none all
the time.
For provider lookups currently its generic/easy and fast as its done
based on eeprom class. Am not sure what advantage would we get
Am I missing anything ?
If you are ok I will prepare a v5 with the proposed changes.
--srini
>
> qfprom: eeprom@58000 {
> compatible = "qcom,qfprom-msm8916";
> reg = <0x58000 0x7000>;
> #eeprom-cells = <0>;
> };
>
> cpr@b018000 {
> compatible = "qcom,cpr";
> reg = <0xb018000 0x1000>;
> interrupts = <0 15 1>, <0 16 1>, <0 17 1>;
> eeproms = <&qfprom>;
> ...
> };
>
^ permalink raw reply
* Re: [PATCH v17 1/2] sys_membarrier(): system-wide memory barrier (generic, x86)
From: Michael Kerrisk (man-pages) @ 2015-05-05 5:56 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Andrew Morton, lkml, Josh Triplett, KOSAKI Motohiro,
Steven Rostedt, Nicholas Miell, Linus Torvalds, Ingo Molnar,
Alan Cox, Lai Jiangshan, Stephen Hemminger, Thomas Gleixner,
Peter Zijlstra, David Howells, Pranith Kumar, Linux API
In-Reply-To: <1430773213-8981-2-git-send-email-mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
[CC += linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]
Since this is a kernel-user-space API change, please CC linux-api@.
The kernel source file Documentation/SubmitChecklist notes that all
Linux kernel patches that change userspace interfaces should be CCed
to linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, so that the various parties who are
interested in API changes are informed. For further information, see
https://www.kernel.org/doc/man-pages/linux-api-ml.html
Thanks,
Michael
On 4 May 2015 at 23:00, Mathieu Desnoyers
<mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org> wrote:
> Here is an implementation of a new system call, sys_membarrier(), which
> executes a memory barrier on all threads running on the system. It is
> implemented by calling synchronize_sched(). It can be used to distribute
> the cost of user-space memory barriers asymmetrically by transforming
> pairs of memory barriers into pairs consisting of sys_membarrier() and a
> compiler barrier. For synchronization primitives that distinguish
> between read-side and write-side (e.g. userspace RCU [1], rwlocks), the
> read-side can be accelerated significantly by moving the bulk of the
> memory barrier overhead to the write-side.
>
> It is based on kernel v4.1-rc2.
>
> To explain the benefit of this scheme, let's introduce two example threads:
>
> Thread A (non-frequent, e.g. executing liburcu synchronize_rcu())
> Thread B (frequent, e.g. executing liburcu
> rcu_read_lock()/rcu_read_unlock())
>
> In a scheme where all smp_mb() in thread A are ordering memory accesses
> with respect to smp_mb() present in Thread B, we can change each
> smp_mb() within Thread A into calls to sys_membarrier() and each
> smp_mb() within Thread B into compiler barriers "barrier()".
>
> Before the change, we had, for each smp_mb() pairs:
>
> Thread A Thread B
> previous mem accesses previous mem accesses
> smp_mb() smp_mb()
> following mem accesses following mem accesses
>
> After the change, these pairs become:
>
> Thread A Thread B
> prev mem accesses prev mem accesses
> sys_membarrier() barrier()
> follow mem accesses follow mem accesses
>
> As we can see, there are two possible scenarios: either Thread B memory
> accesses do not happen concurrently with Thread A accesses (1), or they
> do (2).
>
> 1) Non-concurrent Thread A vs Thread B accesses:
>
> Thread A Thread B
> prev mem accesses
> sys_membarrier()
> follow mem accesses
> prev mem accesses
> barrier()
> follow mem accesses
>
> In this case, thread B accesses will be weakly ordered. This is OK,
> because at that point, thread A is not particularly interested in
> ordering them with respect to its own accesses.
>
> 2) Concurrent Thread A vs Thread B accesses
>
> Thread A Thread B
> prev mem accesses prev mem accesses
> sys_membarrier() barrier()
> follow mem accesses follow mem accesses
>
> In this case, thread B accesses, which are ensured to be in program
> order thanks to the compiler barrier, will be "upgraded" to full
> smp_mb() by synchronize_sched().
>
> * Benchmarks
>
> On Intel Xeon E5405 (8 cores)
> (one thread is calling sys_membarrier, the other 7 threads are busy
> looping)
>
> 1000 non-expedited sys_membarrier calls in 33s = 33 milliseconds/call.
>
> * User-space user of this system call: Userspace RCU library
>
> Both the signal-based and the sys_membarrier userspace RCU schemes
> permit us to remove the memory barrier from the userspace RCU
> rcu_read_lock() and rcu_read_unlock() primitives, thus significantly
> accelerating them. These memory barriers are replaced by compiler
> barriers on the read-side, and all matching memory barriers on the
> write-side are turned into an invocation of a memory barrier on all
> active threads in the process. By letting the kernel perform this
> synchronization rather than dumbly sending a signal to every process
> threads (as we currently do), we diminish the number of unnecessary wake
> ups and only issue the memory barriers on active threads. Non-running
> threads do not need to execute such barrier anyway, because these are
> implied by the scheduler context switches.
>
> Results in liburcu:
>
> Operations in 10s, 6 readers, 2 writers:
>
> memory barriers in reader: 1701557485 reads, 3129842 writes
> signal-based scheme: 9825306874 reads, 5386 writes
> sys_membarrier: 7992076602 reads, 220 writes
>
> The dynamic sys_membarrier availability check adds some overhead to
> the read-side compared to the signal-based scheme, but besides that,
> with the expedited scheme, we can see that we are close to the read-side
> performance of the signal-based scheme. However, this non-expedited
> sys_membarrier implementation has a much slower grace period than signal
> and memory barrier schemes.
>
> An expedited version of this system call can be added later on to speed
> up the grace period. Its implementation will likely depend on reading
> the cpu_curr()->mm without holding each CPU's rq lock.
>
> This patch adds the system call to x86 and to asm-generic.
>
> membarrier(2) man page:
> --------------- snip -------------------
> MEMBARRIER(2) Linux Programmer's Manual MEMBARRIER(2)
>
> NAME
> membarrier - issue memory barriers on a set of threads
>
> SYNOPSIS
> #include <linux/membarrier.h>
>
> int membarrier(int cmd, int flags);
>
> DESCRIPTION
> The cmd argument is one of the following:
>
> MEMBARRIER_CMD_QUERY
> Query the set of supported commands. It returns a bitmask of
> supported commands.
>
> MEMBARRIER_CMD_SHARED
> Execute a memory barrier on all threads running on the system.
> Upon return from system call, the caller thread is ensured that
> all running threads have passed through a state where all memory
> accesses to user-space addresses match program order between
> entry to and return from the system call (non-running threads
> are de facto in such a state). This covers threads from all pro‐
> cesses running on the system. This command returns 0.
>
> The flags argument needs to be 0. For future extensions.
>
> All memory accesses performed in program order from each targeted
> thread is guaranteed to be ordered with respect to sys_membarrier(). If
> we use the semantic "barrier()" to represent a compiler barrier forcing
> memory accesses to be performed in program order across the barrier,
> and smp_mb() to represent explicit memory barriers forcing full memory
> ordering across the barrier, we have the following ordering table for
> each pair of barrier(), sys_membarrier() and smp_mb():
>
> The pair ordering is detailed as (O: ordered, X: not ordered):
>
> barrier() smp_mb() sys_membarrier()
> barrier() X X O
> smp_mb() X O O
> sys_membarrier() O O O
>
> RETURN VALUE
> On success, these system calls return zero. On error, -1 is returned,
> and errno is set appropriately. For a given command, with flags
> argument set to 0, this system call is guaranteed to always return the
> same value until reboot.
>
> ERRORS
> ENOSYS System call is not implemented.
>
> EINVAL Invalid arguments.
>
> Linux 2015-04-15 MEMBARRIER(2)
> --------------- snip -------------------
>
> [1] http://urcu.so
>
> Changes since v16:
> - Update documentation.
> - Add man page to changelog.
> - Build sys_membarrier on !CONFIG_SMP. It allows userspace applications
> to not care about the number of processors on the system. Based on
> recommendations from Stephen Hemminger and Steven Rostedt.
> - Check that flags argument is 0, update documentation to require it.
>
> Changes since v15:
> - Add flags argument in addition to cmd.
> - Update documentation.
>
> Changes since v14:
> - Take care of Thomas Gleixner's comments.
>
> Changes since v13:
> - Move to kernel/membarrier.c.
> - Remove MEMBARRIER_PRIVATE flag.
> - Add MAINTAINERS file entry.
>
> Changes since v12:
> - Remove _FLAG suffix from uapi flags.
> - Add Expert menuconfig option CONFIG_MEMBARRIER (default=y).
> - Remove EXPEDITED mode. Only implement non-expedited for now, until
> reading the cpu_curr()->mm can be done without holding the CPU's rq
> lock.
>
> Changes since v11:
> - 5 years have passed.
> - Rebase on v3.19 kernel.
> - Add futex-alike PRIVATE vs SHARED semantic: private for per-process
> barriers, non-private for memory mappings shared between processes.
> - Simplify user API.
> - Code refactoring.
>
> Changes since v10:
> - Apply Randy's comments.
> - Rebase on 2.6.34-rc4 -tip.
>
> Changes since v9:
> - Clean up #ifdef CONFIG_SMP.
>
> Changes since v8:
> - Go back to rq spin locks taken by sys_membarrier() rather than adding
> memory barriers to the scheduler. It implies a potential RoS
> (reduction of service) if sys_membarrier() is executed in a busy-loop
> by a user, but nothing more than what is already possible with other
> existing system calls, but saves memory barriers in the scheduler fast
> path.
> - re-add the memory barrier comments to x86 switch_mm() as an example to
> other architectures.
> - Update documentation of the memory barriers in sys_membarrier and
> switch_mm().
> - Append execution scenarios to the changelog showing the purpose of
> each memory barrier.
>
> Changes since v7:
> - Move spinlock-mb and scheduler related changes to separate patches.
> - Add support for sys_membarrier on x86_32.
> - Only x86 32/64 system calls are reserved in this patch. It is planned
> to incrementally reserve syscall IDs on other architectures as these
> are tested.
>
> Changes since v6:
> - Remove some unlikely() not so unlikely.
> - Add the proper scheduler memory barriers needed to only use the RCU
> read lock in sys_membarrier rather than take each runqueue spinlock:
> - Move memory barriers from per-architecture switch_mm() to schedule()
> and finish_lock_switch(), where they clearly document that all data
> protected by the rq lock is guaranteed to have memory barriers issued
> between the scheduler update and the task execution. Replacing the
> spin lock acquire/release barriers with these memory barriers imply
> either no overhead (x86 spinlock atomic instruction already implies a
> full mb) or some hopefully small overhead caused by the upgrade of the
> spinlock acquire/release barriers to more heavyweight smp_mb().
> - The "generic" version of spinlock-mb.h declares both a mapping to
> standard spinlocks and full memory barriers. Each architecture can
> specialize this header following their own need and declare
> CONFIG_HAVE_SPINLOCK_MB to use their own spinlock-mb.h.
> - Note: benchmarks of scheduler overhead with specialized spinlock-mb.h
> implementations on a wide range of architecture would be welcome.
>
> Changes since v5:
> - Plan ahead for extensibility by introducing mandatory/optional masks
> to the "flags" system call parameter. Past experience with accept4(),
> signalfd4(), eventfd2(), epoll_create1(), dup3(), pipe2(), and
> inotify_init1() indicates that this is the kind of thing we want to
> plan for. Return -EINVAL if the mandatory flags received are unknown.
> - Create include/linux/membarrier.h to define these flags.
> - Add MEMBARRIER_QUERY optional flag.
>
> Changes since v4:
> - Add "int expedited" parameter, use synchronize_sched() in the
> non-expedited case. Thanks to Lai Jiangshan for making us consider
> seriously using synchronize_sched() to provide the low-overhead
> membarrier scheme.
> - Check num_online_cpus() == 1, quickly return without doing nothing.
>
> Changes since v3a:
> - Confirm that each CPU indeed runs the current task's ->mm before
> sending an IPI. Ensures that we do not disturb RT tasks in the
> presence of lazy TLB shootdown.
> - Document memory barriers needed in switch_mm().
> - Surround helper functions with #ifdef CONFIG_SMP.
>
> Changes since v2:
> - simply send-to-many to the mm_cpumask. It contains the list of
> processors we have to IPI to (which use the mm), and this mask is
> updated atomically.
>
> Changes since v1:
> - Only perform the IPI in CONFIG_SMP.
> - Only perform the IPI if the process has more than one thread.
> - Only send IPIs to CPUs involved with threads belonging to our process.
> - Adaptative IPI scheme (single vs many IPI with threshold).
> - Issue smp_mb() at the beginning and end of the system call.
>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Paul E. McKenney <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> CC: Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>
> CC: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> CC: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
> CC: Nicholas Miell <nmiell-Wuw85uim5zDR7s880joybQ@public.gmane.org>
> CC: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> CC: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> CC: Alan Cox <gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
> CC: Lai Jiangshan <laijs-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
> CC: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
> CC: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> CC: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> CC: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> CC: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> CC: "Pranith Kumar" <bobby.prani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> MAINTAINERS | 8 ++++
> arch/x86/syscalls/syscall_32.tbl | 1 +
> arch/x86/syscalls/syscall_64.tbl | 1 +
> include/linux/syscalls.h | 2 +
> include/uapi/asm-generic/unistd.h | 4 ++-
> include/uapi/linux/Kbuild | 1 +
> include/uapi/linux/membarrier.h | 53 +++++++++++++++++++++++++++++
> init/Kconfig | 12 +++++++
> kernel/Makefile | 1 +
> kernel/membarrier.c | 66 +++++++++++++++++++++++++++++++++++++
> kernel/sys_ni.c | 3 ++
> 11 files changed, 151 insertions(+), 1 deletions(-)
> create mode 100644 include/uapi/linux/membarrier.h
> create mode 100644 kernel/membarrier.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 781e099..fcb63d4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6370,6 +6370,14 @@ W: http://www.mellanox.com
> Q: http://patchwork.ozlabs.org/project/netdev/list/
> F: drivers/net/ethernet/mellanox/mlx4/en_*
>
> +MEMBARRIER SUPPORT
> +M: Mathieu Desnoyers <mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
> +M: "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> +L: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +S: Supported
> +F: kernel/membarrier.c
> +F: include/uapi/linux/membarrier.h
> +
> MEMORY MANAGEMENT
> L: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
> W: http://www.linux-mm.org
> diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
> index ef8187f..e63ad61 100644
> --- a/arch/x86/syscalls/syscall_32.tbl
> +++ b/arch/x86/syscalls/syscall_32.tbl
> @@ -365,3 +365,4 @@
> 356 i386 memfd_create sys_memfd_create
> 357 i386 bpf sys_bpf
> 358 i386 execveat sys_execveat stub32_execveat
> +359 i386 membarrier sys_membarrier
> diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
> index 9ef32d5..87f3cd6 100644
> --- a/arch/x86/syscalls/syscall_64.tbl
> +++ b/arch/x86/syscalls/syscall_64.tbl
> @@ -329,6 +329,7 @@
> 320 common kexec_file_load sys_kexec_file_load
> 321 common bpf sys_bpf
> 322 64 execveat stub_execveat
> +323 common membarrier sys_membarrier
>
> #
> # x32-specific system call numbers start at 512 to avoid cache impact
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 76d1e38..51a9054 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -884,4 +884,6 @@ asmlinkage long sys_execveat(int dfd, const char __user *filename,
> const char __user *const __user *argv,
> const char __user *const __user *envp, int flags);
>
> +asmlinkage long sys_membarrier(int cmd, int flags);
> +
> #endif
> diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> index e016bd9..8da542a 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -709,9 +709,11 @@ __SYSCALL(__NR_memfd_create, sys_memfd_create)
> __SYSCALL(__NR_bpf, sys_bpf)
> #define __NR_execveat 281
> __SC_COMP(__NR_execveat, sys_execveat, compat_sys_execveat)
> +#define __NR_membarrier 282
> +__SYSCALL(__NR_membarrier, sys_membarrier)
>
> #undef __NR_syscalls
> -#define __NR_syscalls 282
> +#define __NR_syscalls 283
>
> /*
> * All syscalls below here should go away really,
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index 1a0006a..7bcc827 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -250,6 +250,7 @@ header-y += mdio.h
> header-y += media.h
> header-y += media-bus-format.h
> header-y += mei.h
> +header-y += membarrier.h
> header-y += memfd.h
> header-y += mempolicy.h
> header-y += meye.h
> diff --git a/include/uapi/linux/membarrier.h b/include/uapi/linux/membarrier.h
> new file mode 100644
> index 0000000..e0b108b
> --- /dev/null
> +++ b/include/uapi/linux/membarrier.h
> @@ -0,0 +1,53 @@
> +#ifndef _UAPI_LINUX_MEMBARRIER_H
> +#define _UAPI_LINUX_MEMBARRIER_H
> +
> +/*
> + * linux/membarrier.h
> + *
> + * membarrier system call API
> + *
> + * Copyright (c) 2010, 2015 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to deal
> + * in the Software without restriction, including without limitation the rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +
> +/**
> + * enum membarrier_cmd - membarrier system call command
> + * @MEMBARRIER_CMD_QUERY: Query the set of supported commands. It returns
> + * a bitmask of valid commands.
> + * @MEMBARRIER_CMD_SHARED: Execute a memory barrier on all running threads.
> + * Upon return from system call, the caller thread
> + * is ensured that all running threads have passed
> + * through a state where all memory accesses to
> + * user-space addresses match program order between
> + * entry to and return from the system call
> + * (non-running threads are de facto in such a
> + * state). This covers threads from all processes
> + * running on the system. This command returns 0.
> + *
> + * Command to be passed to the membarrier system call. The commands need to
> + * be a single bit each, except for MEMBARRIER_CMD_QUERY which is assigned to
> + * the value 0.
> + */
> +enum membarrier_cmd {
> + MEMBARRIER_CMD_QUERY = 0,
> + MEMBARRIER_CMD_SHARED = (1 << 0),
> +};
> +
> +#endif /* _UAPI_LINUX_MEMBARRIER_H */
> diff --git a/init/Kconfig b/init/Kconfig
> index dc24dec..307e406 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1583,6 +1583,18 @@ config PCI_QUIRKS
> bugs/quirks. Disable this only if your target machine is
> unaffected by PCI quirks.
>
> +config MEMBARRIER
> + bool "Enable membarrier() system call" if EXPERT
> + default y
> + help
> + Enable the membarrier() system call that allows issuing memory
> + barriers across all running threads, which can be used to distribute
> + the cost of user-space memory barriers asymmetrically by transforming
> + pairs of memory barriers into pairs consisting of membarrier() and a
> + compiler barrier.
> +
> + If unsure, say Y.
> +
> config EMBEDDED
> bool "Embedded system"
> option allnoconfig_y
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 60c302c..05191fd 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -98,6 +98,7 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> obj-$(CONFIG_JUMP_LABEL) += jump_label.o
> obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
> obj-$(CONFIG_TORTURE_TEST) += torture.o
> +obj-$(CONFIG_MEMBARRIER) += membarrier.o
>
> $(obj)/configs.o: $(obj)/config_data.h
>
> diff --git a/kernel/membarrier.c b/kernel/membarrier.c
> new file mode 100644
> index 0000000..a20b279
> --- /dev/null
> +++ b/kernel/membarrier.c
> @@ -0,0 +1,66 @@
> +/*
> + * Copyright (C) 2010, 2015 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> + *
> + * membarrier system call
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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/syscalls.h>
> +#include <linux/membarrier.h>
> +
> +/*
> + * Bitmask made from a "or" of all commands within enum membarrier_cmd,
> + * except MEMBARRIER_CMD_QUERY.
> + */
> +#define MEMBARRIER_CMD_BITMASK (MEMBARRIER_CMD_SHARED)
> +
> +/**
> + * sys_membarrier - issue memory barriers on a set of threads
> + * @cmd: Takes command values defined in enum membarrier_cmd.
> + * @flags: Currently needs to be 0. For future extensions.
> + *
> + * If this system call is not implemented, -ENOSYS is returned. If the
> + * command specified does not exist, or if the command argument is invalid,
> + * this system call returns -EINVAL. For a given command, with flags argument
> + * set to 0, this system call is guaranteed to always return the same value
> + * until reboot.
> + *
> + * All memory accesses performed in program order from each targeted thread
> + * is guaranteed to be ordered with respect to sys_membarrier(). If we use
> + * the semantic "barrier()" to represent a compiler barrier forcing memory
> + * accesses to be performed in program order across the barrier, and
> + * smp_mb() to represent explicit memory barriers forcing full memory
> + * ordering across the barrier, we have the following ordering table for
> + * each pair of barrier(), sys_membarrier() and smp_mb():
> + *
> + * The pair ordering is detailed as (O: ordered, X: not ordered):
> + *
> + * barrier() smp_mb() sys_membarrier()
> + * barrier() X X O
> + * smp_mb() X O O
> + * sys_membarrier() O O O
> + */
> +SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
> +{
> + if (flags)
> + return -EINVAL;
> + switch (cmd) {
> + case MEMBARRIER_CMD_QUERY:
> + return MEMBARRIER_CMD_BITMASK;
> + case MEMBARRIER_CMD_SHARED:
> + if (num_online_cpus() > 1)
> + synchronize_sched();
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}
> diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
> index 7995ef5..eb4fde0 100644
> --- a/kernel/sys_ni.c
> +++ b/kernel/sys_ni.c
> @@ -243,3 +243,6 @@ cond_syscall(sys_bpf);
>
> /* execveat */
> cond_syscall(sys_execveat);
> +
> +/* membarrier */
> +cond_syscall(sys_membarrier);
> --
> 1.7.7.3
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [PATCH net-next] tcp: provide SYN headers for passive connections
From: John Heffner @ 2015-05-05 3:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric B Munson, Tom Herbert, David S. Miller,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <1430752330.3711.180.camel-XN9IlZ5yJG9HTL0Zs8A6p/gx64E7kk8eUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
On Mon, May 4, 2015 at 11:12 AM, Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, 2015-05-04 at 10:41 -0400, John Heffner wrote:
>
>> Nice idea, seems handy. But a couple (somewhat related) questions:
>>
>> * Other than convenience, are there reasons not use an existing, more
>> general-purpose and portable mechanism like pcap? (Permissions, I
>> guess?)
>
> Very hard to synchronize when say you have 32 listeners sharing a single
> port (SO_REUSEPORT), and receive one million SYN per second (when my TCP
> listener scaling work is finished).
>
> libpcap here would be a serious bottleneck, even with a clever FANIN
> support on the af_packet sockets, considering use of multiqueue NIC.
>
>> * Are there conditions where, for security purposes, you don't want an
>> application to have access to the raw SYNs?
>
> Not that we are aware of : We restrict the access to IP + TCP headers,
> for the passive part. All information that is available there was
> provided by the remote peer on a 'open way' anyway.
Makes sense, thanks.
-John
^ permalink raw reply
* Re: [RFC PATCH 1/3] iio: export mounting matrix information
From: Octavian Purdila @ 2015-05-04 17:48 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lars-Peter Clausen, Peter Meerwald, Robert Moore,
Rafael J Wysocki, Len Brown, linux-api-u79uwXL29TY76Z2rM5mHXA,
lkml, linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <55475710.9050707-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Mon, May 4, 2015 at 2:25 PM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On 27/04/15 16:01, Octavian Purdila wrote:
>> Export a new sysfs attribute that describes the placement of the
>> sensor on the device in the form of a mounting matrix so that
>> userspace can do the required correction to get accurate data:
>>
>> corrected X = MM[0] * X + MM[1] Y + MM[2] * Z
>> corrected Y = MM[3] * X + MM[4] Y + MM[5] * Z
>> corrected Z = MM[6] * X + MM[7] Y + MM[8] * Z
>>
>> This information is read from the device properties of the parent of
>> the IIO device.
>>
>> Signed-off-by: Octavian Purdila <octavian.purdila-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Hmm. This could be done with existing code and a new info_mask element.
> The disadvantage is you'd have to change the read_raw to read_raw_multi
> callback, but that's hardly a big job. If I could be bothered, I'd
> move the whole subsystem over and drop read_raw entirely.
>
> It was introduced precisely for this sort of element.
If I understand this correctly this will require changing every driver
that want to expose this information. However, this information is
independent of the driver, as this information is read from the device
tree or ACPI. As such, doesn't this fits better in the IIO core?
> As I mentioned deeper in the thread. If we are going to introduce a mounting
> matrix, I'd prefer a version that includes translation. It might not matter
> to many devices but it has mattered a lot to me in the past and doesn't hurt
> others that much (I used to write papers on how to estimate this stuff
> from black box devices).
OK, I will look into that.
>> ---
>> Documentation/ABI/testing/sysfs-bus-iio | 11 +++++++++
>> drivers/iio/industrialio-core.c | 42 +++++++++++++++++++++++++++++++++
>> include/linux/iio/iio.h | 9 +++++++
>> 3 files changed, 62 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
>> index 866b4ec..d36476e 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-iio
>> +++ b/Documentation/ABI/testing/sysfs-bus-iio
>> @@ -1375,3 +1375,14 @@ Description:
>> The emissivity ratio of the surface in the field of view of the
>> contactless temperature sensor. Emissivity varies from 0 to 1,
>> with 1 being the emissivity of a black body.
>> +
>> +What: /sys/bus/iio/devices/iio:deviceX/mounting_matrix
>> +KernelVersion: 4.2
>> +Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> +Description:
>> + A list of 9 floating point values that describes the
>> + transformation needed to account for the way the sensor has been
>> + placed on the PCB:
>> + corrected X = MM[0] * X + MM[1] Y + MM[2] * Z
>> + corrected Y = MM[3] * X + MM[4] Y + MM[5] * Z
>> + corrected Z = MM[6] * X + MM[7] Y + MM[8] * Z
>> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
>> index 7c98bc1..9000c53 100644
>> --- a/drivers/iio/industrialio-core.c
>> +++ b/drivers/iio/industrialio-core.c
>> @@ -871,6 +871,45 @@ static ssize_t iio_show_dev_name(struct device *dev,
>>
>> static DEVICE_ATTR(name, S_IRUGO, iio_show_dev_name, NULL);
>>
>> +static bool iio_get_mounting_matrix(struct iio_dev *indio_dev)
>> +{
>> + int i, err;
>> +
>> + err = device_property_read_u32_array(&indio_dev->dev, "mounting-matrix",
>> + indio_dev->mounting_matrix, 9);
>> + if (!err) {
>> + int *mm = indio_dev->mounting_matrix;
>> +
>> + for (i = IIO_MM_SIZE - 2; i > 0; i -= 2) {
>> + mm[i] = mm[i / 2];
>> + mm[i + 1] = 0;
>> + }
>> +
>> + return true;
>> + }
>> +
>> + return false;
>> +}
>> +
>> +static ssize_t iio_show_mounting_matrix(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>> + char *tmp = buf;
>> + int i;
>> +
>> + for (i = 0; i < IIO_MM_SIZE; i += 2) {
>> + tmp += iio_format_value(tmp, IIO_VAL_INT_PLUS_MICRO, 2,
>> + &indio_dev->mounting_matrix[i]);
>> + if (((i + 2) / 2) % 3)
> Hmm. if (i != 8) should also do the job with slightly less feedling of
> magic..
>> + tmp[-1] = ' ';
>> + }
>> + return tmp - buf;
>> +}
>> +
>> +static DEVICE_ATTR(mounting_matrix, S_IRUGO, iio_show_mounting_matrix, NULL);
>> +
>> static int iio_device_register_sysfs(struct iio_dev *indio_dev)
>> {
>> int i, ret = 0, attrcount, attrn, attrcount_orig = 0;
>> @@ -920,6 +959,9 @@ static int iio_device_register_sysfs(struct iio_dev *indio_dev)
>> indio_dev->chan_attr_group.attrs[attrn++] = &p->dev_attr.attr;
>> if (indio_dev->name)
>> indio_dev->chan_attr_group.attrs[attrn++] = &dev_attr_name.attr;
>> + if (iio_get_mounting_matrix(indio_dev))
>> + indio_dev->chan_attr_group.attrs[attrn++] =
>> + &dev_attr_mounting_matrix.attr;
>>
>> indio_dev->groups[indio_dev->groupcounter++] =
>> &indio_dev->chan_attr_group;
>> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
>> index b1e46ae..c1fa852 100644
>> --- a/include/linux/iio/iio.h
>> +++ b/include/linux/iio/iio.h
>> @@ -434,6 +434,8 @@ struct iio_buffer_setup_ops {
>> const unsigned long *scan_mask);
>> };
>>
>> +#define IIO_MM_SIZE 18
>> +
>> /**
>> * struct iio_dev - industrial I/O device
>> * @id: [INTERN] used to identify device internally
>> @@ -469,6 +471,12 @@ struct iio_buffer_setup_ops {
>> * @groups: [INTERN] attribute groups
>> * @groupcounter: [INTERN] index of next attribute group
>> * @flags: [INTERN] file ops related flags including busy flag.
> Hmm. No absolute need to have this new data in the iio_dev. I'd do it
> via the read_raw_multi callback, though this will require converting read_raw
> over to that more flexible version.
>> + * @mounting_matrix: [INTERN] the mounting matrix is a series of 9
>> + * IIO_VAL_INT_PLUS_MICRO pairs that describes the
>> + * transformation needed to account for the way the sensor
>> + * has been placed on the PCB. See the mounting_matrix
>> + * entry in Documentation/ABI/testing/sysfs-bus-iio about
>> + * details of the transformation operations.
>> * @debugfs_dentry: [INTERN] device specific debugfs dentry.
>> * @cached_reg_addr: [INTERN] cached register address for debugfs reads.
>> */
>> @@ -509,6 +517,7 @@ struct iio_dev {
>> int groupcounter;
>>
>> unsigned long flags;
>> + int mounting_matrix[IIO_MM_SIZE];
>> #if defined(CONFIG_DEBUG_FS)
>> struct dentry *debugfs_dentry;
>> unsigned cached_reg_addr;
>>
>
^ permalink raw reply
* Re: [RFC PATCH 2/3] iio: allow better control for flushing the hardware fifo
From: Octavian Purdila @ 2015-05-04 15:36 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Jonathan Cameron, Hartmut Knaack, Peter Meerwald,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lkml,
Adriana Reus, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5547846F.50604-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
On Mon, May 4, 2015 at 5:38 PM, Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> wrote:
> On 05/03/2015 08:11 AM, Octavian Purdila wrote:
>>
>> On Sat, May 2, 2015 at 8:42 PM, Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
>> wrote:
>>>
>>> On 04/29/2015 01:18 PM, Octavian Purdila wrote:
>>>>
>>>>
>>>> Some applications need to be able to flush [1] the hardware fifo of
>>>> the device and to receive events of when that happened [2] so that it
>>>> can ignore stale data.
>>>>
>>>> This patch adds a new event (IIO_EV_TYPE_HWFIFO_FLUSHED) that should
>>>> be sent to userspace when a flush has been completed. The application
>>>> will be able to identify which are the samples to ignore based on the
>>>> timestamp of the event.
>>>>
>>>> To allow applications to accurately generate a hardware fifo flush on
>>>> demand, this patch also adds a new sysfs entry that triggers a
>>>> hardware fifo flush when written to.
>>>>
>>>> [1]
>>>>
>>>> https://source.android.com/devices/sensors/hal-interface.html#flush_sensor
>>>> [2]
>>>>
>>>> https://source.android.com/devices/sensors/hal-interface.html#metadata_flush_complete_events
>>>
>>>
>>>
>>> Since there is no asynchronous queue for commands to be executed in IIO
>>> adding a asynchronous completion event doesn't make too much sense. This
>>> is
>>> something that needs to be handled at the HAL level.
>>>
>>> The HAL needs to have a queue of commands that need to be executed where
>>> new
>>> events can be added asynchronously, then has a loop which goes through
>>> the
>>> commands in the queue and executes them, and once executed generated the
>>> appropriate completion event.
>>>
>>
>> Hi Lars,
>>
>> Thanks for the review.
>>
>> We can't do this at the HAL level because the needed information is
>> only available at the HAL level. At the HAL level each received sample
>> from the driver is converted to an event. When doing a flush the HAL
>> must add a special event (flush complete) after the last sample in the
>> hardware fifo. But the HAL does not know how many samples are in the
>> hardware fifo, how many are in the device buffer, etc.
>
>
> Ok, so that's what you need the timestamp for I presume? So the signature of
> the of the sync function is basically.
>
> timestamp sync(device)
>
> where timestamp is greater or equal to the timestamp of all samples before
> the sync and smaller or equal to all samples after the sync.
>
Yes that is the idea, although the implementation is that we need to
insert an Android flush_complete event right before the event with the
timestamp strictly greater then the timestamp of the IIO fifo flushed
event.
> What your implementation does is implement a synchronous API to flush the
> FIFO but delivers the result of the operation asynchronously via a rather
> arbitrary delivery mechanism. That is in my opinion not a good API/ABI and
> might even have some race condition issues.
>
> If you do a flush, then read as much data as available you know that this
> data is from before the flush and any data read at a later point is after
> the flush.
>
We tried something similar (read in a loop until -EGAIN was received)
but run into issue where we needed to cycle a lot to get the -EAGAIN
at high sample frequencies and our guess was that read() is taking
more then the time to receive a new sample.
But if we modify the non-blocking case to flush the fifo even when the
available data is non-zero and we have requested more than what is
available I think we can avoid that issue. We'll try that and I'll get
back with more datapoints.
>>
>>>
>>> I really wish that document would specify what is actually meant by
>>> flush.
>>> Copy the FIFO content to a software buffer or discard the FIFO content.
>>>
>>
>> It does say: "... and flushes the FIFO; those events are delivered as
>> usual (i.e.: as if the maximum reporting latency had expired) ..."
>>
>
> Missed that, thanks.
>
>
>>>
>>>>
>>>> Signed-off-by: Octavian Purdila <octavian.purdila-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>>> ---
>>>> Documentation/ABI/testing/sysfs-bus-iio | 11 +++++++++++
>>>> include/linux/iio/sysfs.h | 3 +++
>>>> include/uapi/linux/iio/types.h | 1 +
>>>> 3 files changed, 15 insertions(+)
>>>>
>>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
>>>> b/Documentation/ABI/testing/sysfs-bus-iio
>>>> index 866b4ec..bb4d8de 100644
>>>> --- a/Documentation/ABI/testing/sysfs-bus-iio
>>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio
>>>> @@ -1375,3 +1375,14 @@ Description:
>>>> The emissivity ratio of the surface in the field of
>>>> view
>>>> of the
>>>> contactless temperature sensor. Emissivity varies from
>>>> 0
>>>> to 1,
>>>> with 1 being the emissivity of a black body.
>>>> +
>>>> +What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_flush
>>>> +KernelVersion: 4.2
>>>> +Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>> +Description:
>>>> + Write only entry that accepts a single strictly positive
>>>> integer
>>>> + specifying the number of samples to flush from the
>>>> hardware fifo
>>>> + to the device buffer. When the flush is completed an
>>>> + IIO_EV_TYPE_HWFIFO_FLUSHED event is generated. The event
>>>> has the
>>>> + timestamp equal with the timestamp of last sample that
>>>> was
>>>> + flushed from the hardware fifo.
>>>
>>>
>>>
>>> I'd prefer this to be handled through the normal read() API rather than
>>> having a side channel for it. Big question is how though. We could
>>> specify
>>> that reading in O_NONBLOCK mode will always read data if it is available
>>> and
>>> not only if it is above the watermark threshold.
>>
>>
>> Do you mean to try and flush when the available data in the device
>> buffer is less then the requested size? That should work and hopefully
>> the ABI change does not matter since the hwfifo stuff has not been
>> released yet.
>
>
> Basically only let poll() and blocking read() block when not enough data is
> available. But for non-blocking read return as much data as possible if data
> is available.
>
>>
>> I prefer the explicit flush though. I think it is better to have the
>> ABIs clearly visible instead of being buried in the details.
>>
>
> Yea, it's a bit tricky. What should be used for this sysfs, IOCTL, read()...
>
> - Lars
^ permalink raw reply
* Re: [RFC PATCH 3/3] iio: derive the mounting matrix from ACPI _PLD objects
From: Srinivas Pandruvada @ 2015-05-04 15:23 UTC (permalink / raw)
To: Octavian Purdila
Cc: sathyanarayanan.kuppuswamy-VuQAYsv1563Yd54FQh9/CA,
Jonathan Cameron, Lars-Peter Clausen, Peter Meerwald,
Robert Moore, Rafael J Wysocki, Len Brown,
linux-api-u79uwXL29TY76Z2rM5mHXA, lkml,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAE1zot+1qGPhquFH8+=MhiXNb-OoqKuiYJae3aATqntFO6Q-Jw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 2015-05-04 at 11:21 +0300, Octavian Purdila wrote:
> On Mon, May 4, 2015 at 4:11 AM, Sathyanarayanan Kuppuswamy
> <sathyanarayanan.kuppuswamy-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> > Hi Octavian,
> >
> > On 04/27/2015 07:23 PM, Octavian Purdila wrote:
> >>
> >> On Tue, Apr 28, 2015 at 12:57 AM, sathyanarayanan kuppuswamy
> >> <sathyanarayanan.kuppuswamy-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> >>>
> >>> Hi
> >>>
> >>> On 04/27/2015 08:54 AM, Octavian Purdila wrote:
> >>>>
> >>>> On Mon, Apr 27, 2015 at 6:42 PM, Kuppuswamy Sathyanarayanan
> >>>> <sathyanarayanan.kuppuswamy-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> >>>>>
> >>>>> Since Acpi framework already exports this info to user space, Why not
> >>>>> do
> >>>>> this derivation in user space code ? Why do we need new ABI, if the
> >>>>> same
> >>>>> can be derived from existing one.
> >>>>>
> >>>> The ABI was added in the previous patch so that we can present the
> >>>> sensor orientation information to userspace even in the case of device
> >>>> tree.
> >>>
> >>> If the main reason for implementing a new ABI is to support DT platforms,
> >>> Why not implement a version of _PLD for device tree ? Don't you think it
> >>> would be much better than adding a new ABI to export redundant
> >>> information ?
> >>>
> >> IMO the mounting matrix is more consistent with the IIO ABIs. Although
> >> I have no issue with repicating _PLD for device tree if people agree
> >> that it is better.
> >
> > Since your main issue is, device tree lacking ABI to specify location
> > information, you should consider fixing it there. Let's wait for others
> > comment on this.
> >
> > If you think mounting matrix provides more information than what is
> > supported
> > by _PLD, then we should consider implementing another ABI. AFAIK, that is
> > not
> > the case here.
> >
> > Adding adding a new ABI to represent the information that can be derived
> > from existing ABI does not seem to be useful.
>
> AFAICS the ACPI _PLD information is not (yet) exported to userspace. This patch:
>
> http://marc.info/?t=140795040700003&r=1&w=2
>
> does not seem to be merged upstream. So there is no existing ABI to
> derive from :)
I don't think there is any major objection to this patch. The author
should just try and see if he can replace to device_* calls.
Thanks,
Srinivas
>
> >>
> >>
> >>> Also the location information of the device is not just specific to iio
> >>> drivers. You should consider that we would have similar requirements for
> >>> devices implemented as input or platform drivers.
> >>
> >> The upstream standard for those sensors where the orientation matters
> >> (accelerometer, gyro, compass) is IIO.
> >>
> >> Granted, there are other device types for which the orientation
> >> information may be useful (e.g. camera). However the actual
> >> interpretation and action to be taken is different for each subsystem
> >> (e.g. in the camera case do the correction via V4L2_CID_HFLIP /
> >> V4L2_CID_VFLIP) so I think it is better to expose it at the subsystem
> >> level in a way consistent with the subsystem's ABIs.
> >
> > I agree that location information is used differently at different
> > sub systems. But my question is why we need a new ABI ?
> >
> > Why not handle it in user space ?
> >
> > -
^ permalink raw reply
* Re: [PATCH net-next] tcp: provide SYN headers for passive connections
From: Eric Dumazet @ 2015-05-04 15:12 UTC (permalink / raw)
To: John Heffner
Cc: Eric B Munson, Tom Herbert, David S. Miller,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <CABrhC0nmsfAyHgJX8zEBDBVfFN=2qXKy7cO0Kbp9R9UCeEYowg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 2015-05-04 at 10:41 -0400, John Heffner wrote:
> Nice idea, seems handy. But a couple (somewhat related) questions:
>
> * Other than convenience, are there reasons not use an existing, more
> general-purpose and portable mechanism like pcap? (Permissions, I
> guess?)
Very hard to synchronize when say you have 32 listeners sharing a single
port (SO_REUSEPORT), and receive one million SYN per second (when my TCP
listener scaling work is finished).
libpcap here would be a serious bottleneck, even with a clever FANIN
support on the af_packet sockets, considering use of multiqueue NIC.
> * Are there conditions where, for security purposes, you don't want an
> application to have access to the raw SYNs?
Not that we are aware of : We restrict the access to IP + TCP headers,
for the passive part. All information that is available there was
provided by the remote peer on a 'open way' anyway.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox