Re: [PATCH] dcache d_drop() bug fix / __d_drop() use fix

[raven]

On Wed, 16 Feb 2005, Jan Blunck wrote:
This is a re-submission of the patch I sent about a month ago.
While working on my code I realized that d_drop() might race against 
__d_lookup(). __d_drop() (which is called by d_drop() after acquiring the 
dcache_lock) is accessing dentry->d_flags to set the DCACHE_UNHASHED flag. 
This shouldn't be done without holding dentry->d_lock, like stated in 
dcache.h:

struct dentry {
...
unsigned int d_flags;   /* protected by d_lock */
   ...
};
Therefore d_drop() must acquire the dentry->d_lock. Likewise every use of 
__d_drop() must acquire that lock.

This patch fixes d_drop() and every grep'able __d_drop() use. This patch is 
against today's http://linux.bkbits.net/linux-2.5.

For my part, in autofs4, I would prefer:
--- linux-2.6.9/fs/autofs4/root.c.d_lock2005-02-16 23:15:18.0 
+0800
+++ linux-2.6.9/fs/autofs4/root.c   2005-02-16 23:15:35.0 +0800
@@ -621,7 +621,7 @@
spin_unlock(&dcache_lock);
return -ENOTEMPTY;
}
-   __d_drop(dentry);
+   d_drop(dentry);
spin_unlock(&dcache_lock);
dput(ino->dentry);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] shared subtrees

[raven]

On Fri, 28 Jan 2005, Mike Waychison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Al Viro wrote:
OK, here comes the first draft of proposed semantics for subtree
sharing.  What we want is being able to propagate events between
the parts of mount trees.  Below is a description of what I think
might be a workable semantics; it does *NOT* describe the data
structures I would consider final and there are considerable
areas where we still need to figure out the right behaviour.
Okay, I'm not convinced that shared subtrees as proposed will work well
with autofs.
OK. I've read the thread but haven't digested it so you'll have to put up 
with some stupid questions.

The idea discussed off-line was this:
When you install an autofs mountpoint, on say /home, a daemon is started
to service the requests.  As far as the admin is concerned, an fs is
mounted in the current namespace, call it namespaceA.  The daemon
actually runs in it's one private namespace: call it namespaceB.
namespaceB receives a new autofs filesystem: call it autofsB.  autofsB
is in it's own p-node.  namespaceA gets an autofsA on /home as well, and
autofsA is 'owned' by autofsB's p-node.
So:
autofsB -> autofsB
and
autofsB -> autofsA
Effectively, namespaceA has a private instance of autofsB in its tree.
The problem is this:
Assume /home/mikew is accessed in namespaceA.  The daemon running in
namespaceB gets the event, and mounts an nfs vfsmount on autofsB.  This
event is propagated back to autofsA.
Which condition (or action) in the definition implies
autofsB -> autofsA
(Problem 1: how do you block access to /home/mikew in namespaceA?)
Next, a CLONE_NS is done in namespaceA, creating namespaceA'.  the
homedir on /home/mikew is also copied.
Now, in namespaceA', what happens when a user umount's /home/mikew?  We
haven't yet determined how to handle umount event propagation, but it
appears likely that it will be *a hard thing to do*.
No I haven't spent enough time on the RFC buy into this one.
So I'll just say it looks like something is missing in this argument.
Perhaps the later is namespaceC?
Assuming the nfs umount succeeds, /home/mikew is accessed again in
namespaceA'.
namespaceC?
(Problem 2: The daemon in namespaceB will see the event, but it already
has something mounted on it's version of /home/mikew.  How does it
'send' a mountpoint to namespaceB.)
- ---
Shared subtrees may help in some adminstrative situations, but don't
look like the right solution for autofs.
Autofs will work with namespaces if the following functionality is added
to the kernel:  The ability to perform mount(2) operations on a
directory fd.
This has been discussed before and quickly vetoed, citing that it is a
security risk.  I still fail to understand how allowing a mount to
happen cross-namespace given a dirfd target is any worse than what is
already possible given a dirfd.  If you don't want someone to play with
your namespace, don't give them a dirfd.
Thoughts?
- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB+r1OdQs4kOxk3/MRAmSpAJ96ix25fjze6o7viCq2DCET9J/AlQCfYlC1
CoLKusJXjL+fYxgwggOCW+w=
=8bTv
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [autofs] automount does not close file descriptors at start

[raven]

On Mon, 21 Feb 2005 [EMAIL PROTECTED] wrote:
On Mon, 21 Feb 2005 12:57:22 +0800, Ian Kent said:
This is the first time I've heard this and the first time I wrote a Unix
daemon was fifteen years ago.
As far as I'm concerned redirecting stdin, stdout and stderr to the null
device, then closing it and setting the process to a be the group leader
(as autofs does) should be all that's needed to daemonize a process.
So are we saying that we don't trust the kernel to reliably duplicate the
state of file handles when we fork?
No, you have it 180 degrees off. ;)
Perhaps the sentence above should start "So you are saying that ...".
I'm arguing that I should'nt have to perform a loop closing file 
descriptors I haven't opened.

We *do* trust the kernel to reliably duplicate the state of file handles.
This confirms above.
So if we're about to do the whole double-fork thing and all that, we want to
loop around and close all the file descriptors we don't want leaking to
the double-forked daemon.  Yes, we do something reasonable with fd 0,1,2 -
but we probably also want to do something with that unclosed fd 3 that's still
open on /etc/mydaemon.cf, and any other file descriptors we've left dangling
in the breeze after initialization.
Now this is a good point.
I don`t do a double fork in autofs (inherited code), although, long ago I 
did.

Do we really need to do a double fork to disassociate from the controlling 
terminal or is a single fork and close etc. enough?

I notice that "setsid()" should do this but I've not seen it bofore.
Is that sufficient to do the job instead of the double fork?
And it looks like the automount process I just started still has a tty, 
grumble 

Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch 2/6] Bind Mount Extensions 0.06

[raven]

On Thu, 24 Feb 2005, Herbert Poetzl wrote:
On Wed, Feb 23, 2005 at 11:01:05PM +, Christoph Hellwig wrote:
On Tue, Feb 22, 2005 at 01:11:29PM +0100, Herbert Poetzl wrote:

;
; Bind Mount Extensions
;
; This part adds the required checks for touch_atime() to allow
; for vfsmount based NOATIME and NODIRATIME
; autofs4 update_atime is the only exception (ignored on purpose)
and that purpose is?
this is based on a statement from Al Viro:
| autofs4 use - AFAICS there we want atime updated unconditionally,
| so calling update_atime() (update atime after checking
| noatime/nodiratime/readonly flags) is wrong.
agreed, maybe a proper fix would be better ...
Did you discuss this with the autofs maintainers?
I've had a look at the patch and I can't see any problem.
autofs4 doesn't use the inode atime for expire purposes but does update it 
in sync with its dentry info struct field that is used for this purpose.

So AFAICS the atime is an external view of expire status, 
but only when updated within the autofs4 module VFS callbacks.

I haven't yet looked at the v3 (autofs) module.
I'll get back if I see an issue there.
Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: autofs4 patch: autofs4_wait can leak memory

[raven]

On Fri, 4 Mar 2005, Jeff Moyer wrote:
Hi,
There is a memory in the autofs4_wait function, if multiple processes are
waiting on the same queue:
Well done Jeff.
I'll update my retrospective patch set.
Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] staging: bcm2835-audio: remove unused macro

[Hendrik v. Raven]

The VC_AUDIO_MAX_MSG_LEN macro is not used by anything in the
bcm2835-audio driver.

Signed-off-by: Hendrik v. Raven 
---
v2:
 - rebased against next-20170214

---
 drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h 
b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
index 928dd6009510..da96f1bc2516 100644
--- a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
+++ b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
@@ -21,9 +21,6 @@
 /* FourCC code used for VCHI connection */
 #define VC_AUDIO_SERVER_NAME  MAKE_FOURCC("AUDS")
 
-/* Maximum message length */
-#define VC_AUDIO_MAX_MSG_LEN  (sizeof(VC_AUDIO_MSG_T))
-
 /*
  *  List of screens that are currently supported
  *  All message types supported for HOST->VC direction
-- 
2.11.0

[PATCH] staging: bcm2835-audio: fix spacing of macro

[Hendrik v. Raven]

removes the unwanted spaces inside of sizeof( ), removing a complaint of
checkpatch.pl. Also removes the second space behind the macro name.

Signed-off-by: Hendrik v. Raven 
---
 drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h 
b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
index 09f07fd891bb..dd2f162b1ccb 100644
--- a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
+++ b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
@@ -22,7 +22,7 @@
 #define VC_AUDIO_SERVER_NAME  MAKE_FOURCC("AUDS")
 
 /* Maximum message length */
-#define VC_AUDIO_MAX_MSG_LEN  (sizeof( VC_AUDIO_MSG_T ))
+#define VC_AUDIO_MAX_MSG_LEN (sizeof(VC_AUDIO_MSG_T))
 
 /*
  *  List of screens that are currently supported
-- 
2.11.0

[PATCH] staging: bcm2835-audio: remove unused macro

[Hendrik v. Raven]

The VC_AUDIO_MAX_MSG_LEN macro is not used anywhere and has coding style
violations.

Signed-off-by: Hendrik v. Raven 
---
 drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h 
b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
index 09f07fd891bb..da96f1bc2516 100644
--- a/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
+++ b/drivers/staging/bcm2835-audio/vc_vchi_audioserv_defs.h
@@ -21,9 +21,6 @@
 /* FourCC code used for VCHI connection */
 #define VC_AUDIO_SERVER_NAME  MAKE_FOURCC("AUDS")
 
-/* Maximum message length */
-#define VC_AUDIO_MAX_MSG_LEN  (sizeof( VC_AUDIO_MSG_T ))
-
 /*
  *  List of screens that are currently supported
  *  All message types supported for HOST->VC direction
-- 
2.11.0

Re: [PATCH v1 3/8] clk: meson: add audio clock divider support

[Hendrik v. Raven]

On Tue, Mar 28, 2017 at 04:46:00PM +0200, Jerome Brunet wrote:
> The audio divider needs a specific clock divider driver.
> With am mpll parent clock, which is able to provide a fairly precise rate,
> the generic divider tends to select low value of the divider. In such case
> the quality of the clock is very poor. For the same final rate, maximizing
> the audio clock divider value and selecting the corresponding mpll rate
> gives better results. This is what this driver aims to acheive. So far, so
> good.
> 
> Signed-off-by: Jerome Brunet 
> ---
>  drivers/clk/meson/Makefile|   2 +-
>  drivers/clk/meson/clk-audio-divider.c | 149 
> ++
>  drivers/clk/meson/clkc.h  |  10 +++
>  3 files changed, 160 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/meson/clk-audio-divider.c
> 
> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> index 349583405b7c..83b6d9d65aa1 100644
> --- a/drivers/clk/meson/Makefile
> +++ b/drivers/clk/meson/Makefile
> @@ -2,6 +2,6 @@
>  # Makefile for Meson specific clk
>  #
>  
> -obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-cpu.o clk-mpll.o
> +obj-$(CONFIG_COMMON_CLK_AMLOGIC) += clk-pll.o clk-cpu.o clk-mpll.o 
> clk-audio-divider.o
>  obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
>  obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
> diff --git a/drivers/clk/meson/clk-audio-divider.c 
> b/drivers/clk/meson/clk-audio-divider.c
> new file mode 100644
> index ..ac713b9ea84a
> --- /dev/null
> +++ b/drivers/clk/meson/clk-audio-divider.c
> @@ -0,0 +1,149 @@
> +/*
> + * Copyright (c) 2017 AmLogic, Inc.
> + * Author: Jerome Brunet 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +/*
> + * i2s master clock divider: The algorithm of the generic clk-divider used 
> with
> + * a very precise clock parent such as the mpll tends to select a low divider
> + * factor. This gives very results with this particular divider, especially 
> with
a "poor" appears to be missing here

> + * high frequencies (> 100 MHz)
> + *
> + * This driver try to select the maximum possible divider with the rate the
> + * upstream clock can provide.
> + */
> +
> +#include 
> +#include "clkc.h"
> +
> +#define to_meson_clk_audio_divider(_hw) container_of(_hw, \
> + struct meson_clk_audio_divider, hw)
> +
> +static int _div_round(unsigned long parent_rate, unsigned long rate,
> +   unsigned long flags)
> +{
> + if (flags & CLK_DIVIDER_ROUND_CLOSEST)
> + return DIV_ROUND_CLOSEST_ULL((u64)parent_rate, rate);
> +
> + return DIV_ROUND_UP_ULL((u64)parent_rate, rate);
> +}
> +
> +static int _get_val(unsigned long parent_rate, unsigned long rate)
> +{
> + return DIV_ROUND_UP_ULL((u64)parent_rate, rate) - 1;
> +}
> +
> +static int _valid_divider(struct clk_hw *hw, int divider)
> +{
> + struct meson_clk_audio_divider *adiv =
> + to_meson_clk_audio_divider(hw);
> + int max_divider;
> + u8 width;
> +
> + width = adiv->div.width;
> + max_divider = 1 << width;
> +
> + if (divider < 1)
> + return 1;
> + else if (divider > max_divider)
> + return max_divider;
> +
> + return divider;
This can be replaced by 
return clamp(divider, 1, max_divider);

> +}
> +
> +static unsigned long audio_divider_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + struct meson_clk_audio_divider *adiv =
> + to_meson_clk_audio_divider(hw);
> + struct parm *p;
> + unsigned long reg, divider;
> +
> + p = &adiv->div;
> + reg = readl(adiv->base + p->reg_off);
> + divider = PARM_GET(p->width, p->shift, reg) + 1;
> +
> + return DIV_ROUND_UP_ULL((u64)parent_rate, divider);
> +}
> +
> +static long audio_divider_round_rate(struct clk_hw *hw,
> +  unsigned long rate,
> +  unsigned long *parent_rate)
> +{
> + struct meson_clk_audio_divider *adiv =
> + to_meson_clk_audio_divider(hw);
> + unsigned long max_prate;
> + int divider;
> +
> + if (!(clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT)) {
> + divider = _div_round(*parent_rate, rate, adiv->flags);
> + divider = _valid_divider(hw, divider);
> + return DIV_ROUND_UP_U