Re: [PATCH] allow strictatime to be set as a global default

[Mandeep Sandhu]

Ah yes...now it makes sense! :)

The current 'word of caution' (about increased I/O load on block
devices), seems mild IMHO. Maybe we should we have a stricter
warning...something like enabling this option might be harmful to the
life of your block device (due to excessive writes) and will also lead
to reduced performance?

HTH,
-mandeep


On Fri, Dec 18, 2015 at 2:12 PM, Raymond Jennings  wrote:
> On Fri, Dec 18, 2015 at 10:50 AM, Mandeep Sandhu
>  wrote:
>>
>> You've removed the strictatime option altogether. So how does that
>> satisfy people who _do_ want it?
>
>
> ...actually it looks like I was an idiot and got my diff backwards when I
> pulled it out of git :P
>
> Here's the correct version.
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index 6ce72d8..4b917eb 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -4,6 +4,17 @@
>
> menu "File systems"
>
> +config DEFAULT_STRICTATIME
> +   bool "Use strictatime by default"
> +   default n
> +   help
> + Use strictatime as a default mount option.
> +
> + Strictatime preserves ancient historic behavior of keeping the
> atime field always up to date.
> + However, it was changed in 2007 to relatime to reduce I/O load on
> block devices.
> +
> + If unsure, say N.
> +
> # Use unaligned word dcache accesses
> config DCACHE_WORD_ACCESS
>bool
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 0570729..48e7c15 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2680,9 +2680,15 @@ long do_mount(const char *dev_name, const char __user
> *dir_name,
> if (retval)
> goto dput_out;
>
> -   /* Default to relatime unless overriden */
> +#ifdef CONFIG_DEFAULT_STRICTATIME
> +   /* Default to strictatime unless overridden */
> +   if (flags & MS_RELATIME)
> +   mnt_flags |= MNT_RELATIME;
> +#else
> +   /* Default to relatime unless overridden */
> if (!(flags & MS_NOATIME))
> mnt_flags |= MNT_RELATIME;
> +#endif
>
>
> /* Separate the per-mountpoint flags */
> if (flags & MS_NOSUID)
>
>
>

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] allow strictatime to be set as a global default

[Raymond Jennings]

On Fri, Dec 18, 2015 at 10:50 AM, Mandeep Sandhu 
 wrote:
> You've removed the strictatime option altogether. So how does that
> satisfy people who _do_ want it?

...actually it looks like I was an idiot and got my diff backwards when 
I pulled it out of git :P

Here's the correct version.

diff --git a/fs/Kconfig b/fs/Kconfig
index 6ce72d8..4b917eb 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -4,6 +4,17 @@

 menu "File systems"

+config DEFAULT_STRICTATIME
+   bool "Use strictatime by default"
+   default n
+   help
+ Use strictatime as a default mount option.
+
+ Strictatime preserves ancient historic behavior of keeping the 
atime field always up to date.
+ However, it was changed in 2007 to relatime to reduce I/O load on 
block devices.
+
+ If unsure, say N.
+
 # Use unaligned word dcache accesses
 config DCACHE_WORD_ACCESS
bool
diff --git a/fs/namespace.c b/fs/namespace.c
index 0570729..48e7c15 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2680,9 +2680,15 @@ long do_mount(const char *dev_name, const char 
__user *dir_name,
if (retval)
goto dput_out;

-   /* Default to relatime unless overriden */
+#ifdef CONFIG_DEFAULT_STRICTATIME
+   /* Default to strictatime unless overridden */
+   if (flags & MS_RELATIME)
+   mnt_flags |= MNT_RELATIME;
+#else
+   /* Default to relatime unless overridden */
if (!(flags & MS_NOATIME))
mnt_flags |= MNT_RELATIME;
+#endif

/* Separate the per-mountpoint flags */
if (flags & MS_NOSUID)




___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [PATCH] allow strictatime to be set as a global default

[Mandeep Sandhu]

You've removed the strictatime option altogether. So how does that
satisfy people who _do_ want it?

Is there some other option that will enable it? Just curious.

-mandeep


On Fri, Dec 18, 2015 at 6:42 AM, Raymond Jennings  wrote:
> I'm aware of a little tiff regarding strictatime in the past, and I
> think I came up with a patch that might help everyone get what they
> want.  I'm already using it myself.
>
> I've had some review on #kernelnewbies for technical issues, how does
> this look?
>
> ---
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index 4b917eb..6ce72d8 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -4,17 +4,6 @@
>
>  menu "File systems"
>
> -config DEFAULT_STRICTATIME
> -   bool "Use strictatime by default"
> -   default n
> -   help
> - Use strictatime as a default mount option.
> -
> - Strictatime preserves ancient historic behavior of keeping the
> atime field always up to date.
> - However, it was changed in 2007 to relatime to reduce I/O load on
> block devices.
> -
> - If unsure, say N.
> -
>  # Use unaligned word dcache accesses
>  config DCACHE_WORD_ACCESS
> bool
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 48e7c15..0570729 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -2680,15 +2680,9 @@ long do_mount(const char *dev_name, const char
> __user *dir_name,
> if (retval)
> goto dput_out;
>
> -#ifdef CONFIG_DEFAULT_STRICTATIME
> -   /* Default to strictatime unless overridden */
> -   if (flags & MS_RELATIME)
> -   mnt_flags |= MNT_RELATIME;
> -#else
> -   /* Default to relatime unless overridden */
> +   /* Default to relatime unless overriden */
> if (!(flags & MS_NOATIME))
> mnt_flags |= MNT_RELATIME;
> -#endif
>
> /* Separate the per-mountpoint flags */
> if (flags & MS_NOSUID)
>
>
>
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Customizing UIO mmap'ing

[Kenneth Adam Miller]

On Fri, Dec 18, 2015 at 9:20 AM, Henry Gomersall <
henry.gomers...@smartacoustics.co.uk> wrote:

> On 18/12/15 14:15, Kenneth Adam Miller wrote:
>
>
> On Fri, Dec 18, 2015 at 7:05 AM, Henry Gomersall <
> henry.gomers...@smartacoustics.co.uk> wrote:
>
>> On 17/12/15 21:35, Kenneth Adam Miller wrote:
>>
>> Generally uio_dmem_genirq.c builds on top of uio.c, which provides a
>> common module basis for isolating code common to the other specific
>> modules. But for a specific purpose, uio_dmem_genirq.c has be either
>> customized or extended in order that specific memory regions can be set as
>> accessible. Most easily, this is done in a first come first serve approach
>> by filling out the details (which exactly?) left missing in
>> uio_dmem_genirq.c, and to start, that would be in uio_of_genirq_match
>> 
>> .
>>
>> Am I correct?
>>
>>
>> It's not always necessary to modify uio_dmem_genirq.
>>
>>
> Is it correct though, that I can use another module to stack on top of
> uio_dmem_genirq, and that the correct thing to modify is in fact the
> variable I mentioned?
>
>
> I don't know the answer to this. I'm pretty new to it myself :)
>

Well for any other readers of this conversation, compared to my previous
(perceived) requirements, I now only need to mmap a specific region of
hardware addresses - nothing about custom allocation within that region. I
can use /dev/mem, but that's perceived to be a potential security issue
that we want to keep mitigated. So, we have decided that a uio driver that
filters for the specific hardware address regions that we allow is
desirable. I think that uio_dmem_genirq would be the way to go about it,
but I am not sure there is any example that exists demonstrating how to
edit and then use it.


>
>
> Henry
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[PATCH] allow strictatime to be set as a global default

[Raymond Jennings]

I'm aware of a little tiff regarding strictatime in the past, and I 
think I came up with a patch that might help everyone get what they 
want.  I'm already using it myself.

I've had some review on #kernelnewbies for technical issues, how does 
this look?

---

diff --git a/fs/Kconfig b/fs/Kconfig
index 4b917eb..6ce72d8 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -4,17 +4,6 @@

 menu "File systems"

-config DEFAULT_STRICTATIME
-   bool "Use strictatime by default"
-   default n
-   help
- Use strictatime as a default mount option.
-
- Strictatime preserves ancient historic behavior of keeping the 
atime field always up to date.
- However, it was changed in 2007 to relatime to reduce I/O load on 
block devices.
-
- If unsure, say N.
-
 # Use unaligned word dcache accesses
 config DCACHE_WORD_ACCESS
bool
diff --git a/fs/namespace.c b/fs/namespace.c
index 48e7c15..0570729 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2680,15 +2680,9 @@ long do_mount(const char *dev_name, const char 
__user *dir_name,
if (retval)
goto dput_out;

-#ifdef CONFIG_DEFAULT_STRICTATIME
-   /* Default to strictatime unless overridden */
-   if (flags & MS_RELATIME)
-   mnt_flags |= MNT_RELATIME;
-#else
-   /* Default to relatime unless overridden */
+   /* Default to relatime unless overriden */
if (!(flags & MS_NOATIME))
mnt_flags |= MNT_RELATIME;
-#endif

/* Separate the per-mountpoint flags */
if (flags & MS_NOSUID)




___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Customizing UIO mmap'ing

[Henry Gomersall]

On 18/12/15 14:15, Kenneth Adam Miller wrote:
>
> On Fri, Dec 18, 2015 at 7:05 AM, Henry Gomersall
>  > wrote:
>
> On 17/12/15 21:35, Kenneth Adam Miller wrote:
>> Generally uio_dmem_genirq.c builds on top of uio.c, which
>> provides a common module basis for isolating code common to the
>> other specific modules. But for a specific purpose,
>> uio_dmem_genirq.c has be either customized or extended in order
>> that specific memory regions can be set as accessible. Most
>> easily, this is done in a first come first serve approach by
>> filling out the details (which exactly?) left missing in
>> uio_dmem_genirq.c, and to start, that would be
>> in uio_of_genirq_match
>> 
>> .
>>
>> Am I correct?
>
> It's not always necessary to modify uio_dmem_genirq.
>
>
> Is it correct though, that I can use another module to stack on top of
> uio_dmem_genirq, and that the correct thing to modify is in fact the
> variable I mentioned? 

I don't know the answer to this. I'm pretty new to it myself :)

Henry


signature.asc
Description: OpenPGP digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Customizing UIO mmap'ing

[Kenneth Adam Miller]

On Fri, Dec 18, 2015 at 7:05 AM, Henry Gomersall <
henry.gomers...@smartacoustics.co.uk> wrote:

> On 17/12/15 21:35, Kenneth Adam Miller wrote:
>
> Generally uio_dmem_genirq.c builds on top of uio.c, which provides a
> common module basis for isolating code common to the other specific
> modules. But for a specific purpose, uio_dmem_genirq.c has be either
> customized or extended in order that specific memory regions can be set as
> accessible. Most easily, this is done in a first come first serve approach
> by filling out the details (which exactly?) left missing in
> uio_dmem_genirq.c, and to start, that would be in uio_of_genirq_match
> 
> .
>
> Am I correct?
>
>
> It's not always necessary to modify uio_dmem_genirq.
>
>
Is it correct though, that I can use another module to stack on top of
uio_dmem_genirq, and that the correct thing to modify is in fact the
variable I mentioned?


> Certainly in cases where the hardware capability can be specified by a
> device tree (e.g. ARM systems), it is possible to specify an address space
> and an IRQ that can be immediately used from userspace with the
> uio_dmem_genirq driver with no modifications.
>
>
This is not our case. I have to programmatically retrieve the regions when
the driver is loaded (I know that's just a matter of putting the right code
in the right callback), and allow that to serve as a match.


> Henry
>
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Customizing UIO mmap'ing

[Henry Gomersall]

On 17/12/15 21:35, Kenneth Adam Miller wrote:
> Generally uio_dmem_genirq.c builds on top of uio.c, which provides a
> common module basis for isolating code common to the other specific
> modules. But for a specific purpose, uio_dmem_genirq.c has be either
> customized or extended in order that specific memory regions can be
> set as accessible. Most easily, this is done in a first come first
> serve approach by filling out the details (which exactly?) left
> missing in uio_dmem_genirq.c, and to start, that would be
> in uio_of_genirq_match
> .
>
> Am I correct?

It's not always necessary to modify uio_dmem_genirq.

Certainly in cases where the hardware capability can be specified by a
device tree (e.g. ARM systems), it is possible to specify an address
space and an IRQ that can be immediately used from userspace with the
uio_dmem_genirq driver with no modifications.

Henry



signature.asc
Description: OpenPGP digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies