On 09/04, Luis R. Rodriguez wrote:
>
> struct driver_private {
> struct kobject kobj;
> struct klist klist_devices;
> struct klist_node knode_bus;
> struct module_kobject *mkobj;
> + struct driver_attach_work *attach_work;
> struct device_driver *driver;
I am not
On 09/04, Luis R. Rodriguez wrote:
>
> From: "Luis R. Rodriguez"
>
> The new umh kill option has allowed kthreads to receive
> kill signals but they are generally accepting all sources
> of kill signals
And I think this is right,
> while the original motivation was to enable
> through the OOM fr
On 08/18, Takashi Iwai wrote:
>
> At Mon, 18 Aug 2014 14:22:17 +0200,
> Oleg Nesterov wrote:
> >
> > On 08/18, Takashi Iwai wrote:
> > >
> > > #define module_long_probe_init(initfn)\
> >
On 08/18, Takashi Iwai wrote:
>
> #define module_long_probe_init(initfn)\
> static int _long_probe_##initfn(void *arg) \
> { \
> module_put_and_exit(initfn());
On 08/17, Luis R. Rodriguez wrote:
>
> In the last iteration that I have stress tested for corner cases I just
> get_task_struct() on the init and then put_task_struct() at the exit, is that
> fine too or are there reasons to prefer the module stuff?
I am fine either way.
I like the Takashi's ide
Damn, sorry for noise ;)
I was going to suggest to introduce module_put_and_exit() to simplify
this and potentially other users, but it already exists. So this code
can use it too without additional complications.
On 08/17, Oleg Nesterov wrote:
> On 08/17, Oleg Nesterov wrote:
> >
>
On 08/17, Oleg Nesterov wrote:
>
> On 08/17, Takashi Iwai wrote:
> >
> > How about just increasing/decreasing the module count for blocking the
> > exit call? For example:
> >
> > #define module_long_probe_init(initfn) \
> >
On 08/17, Takashi Iwai wrote:
>
> How about just increasing/decreasing the module count for blocking the
> exit call? For example:
>
> #define module_long_probe_init(initfn)\
> static int _long_probe_##initfn(void *arg) \
> {
On 08/15, Luis R. Rodriguez wrote:
>
> On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
> > On 08/12, Luis R. Rodriguez wrote:
> > >
> > > +/* To be used by modules which can take over 30 seconds at probe */
> >
> > Probably the comment sh
On 08/12, Luis R. Rodriguez wrote:
>
> +/* To be used by modules which can take over 30 seconds at probe */
Probably the comment should explain that this hack should only be
used if the driver is buggy and is wating for "real fix".
> +#define module_long_probe_init(initfn)
On 03/22, James Bottomley wrote:
>
> OK, the fix from the SCSI point of view is to make the mpt teardown path
> actually work. The whole thing looks to be a complete mess because
> there's another place where it will do the wrong thing in
> mptscsih_remove(). You always have to call mpt_detach()
On 03/22, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
> > Tetsuo, what do you think?
>
> I don't like blocking SIGKILL while doing operations that depend on memory
> allocation by other processes. If the OOM killer is triggered and it chose
> the process blocking SIG
On 03/21, Linus Torvalds wrote:
>
> On Fri, Mar 21, 2014 at 11:34 AM, Oleg Nesterov wrote:
> >
> > Yes, it seems that it actually needs > 30 secs. It spends most of the time
> > (30.13286 seconds) in [..]
>
> So how about taking a completely different approach:
D
On 03/20, Oleg Nesterov wrote:
>
> On 03/20, Joseph Salisbury wrote:
> >
> > There was some testing done with your test kernel. The data collected
> > while running your kernel is available in the bug report:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/
On 03/20, Joseph Salisbury wrote:
>
> On 03/19/2014 03:42 PM, Oleg Nesterov wrote:
> > On 03/19, Oleg Nesterov wrote:
> >> On 03/19, Oleg Nesterov wrote:
> >>> But please do not forget that the kernel crashes. Whatever else we do,
> >>> this
> >
On 03/19, Oleg Nesterov wrote:
>
> On 03/19, Oleg Nesterov wrote:
> >
> > But please do not forget that the kernel crashes. Whatever else we do, this
> > should be fixed anyway. And this should be fixed in driver.
>
> drivers/message/fusion/ is obviously buggy.
Pe
On 03/19, Oleg Nesterov wrote:
>
> But please do not forget that the kernel crashes. Whatever else we do, this
> should be fixed anyway. And this should be fixed in driver.
drivers/message/fusion/ is obviously buggy.
mptsas_probe() does
sh = scsi_h
On 03/19, Joseph Salisbury wrote:
>
> On 03/19/2014 07:49 AM, Tetsuo Handa wrote:
Hmm. Apparently I missed this email from Tetsuo. I'll reply here.
> > Oleg Nesterov wrote:
> >
> >> And btw, it is not clear to me if in this case device initialization really
>
On 03/18, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
> > If we need the urgent hack to fix the regression, then I suggest to change
> > scsi_host_alloc() temporary until mptsas (or whatever) is fixed.
>
> Device initialization taking longer than 30 seconds is possible an
On 03/17, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
> >
> > Personally I really dislike this hack. And btw, why we return -ENOMEM if
> > SIGKILL'ed? Why not EINTR ?
>
> I chose -ENOMEM because -ENOMEM looked better for conveying that current
> thread
>
On 12/24, Suresh Thiagarajan wrote:
>
> Below is a small pseudo code on protecting/serializing the flag for global
> access.
> struct temp
> {
> ...
> spinlock_t lock;
> unsigned long lock_flags;
> };
> void my_lock(struct temp *t)
> {
>unsigned long flag; // thre
On 12/23, Ingo Molnar wrote:
>
> * Oleg Nesterov wrote:
>
> > Initially I thought that this is obviously wrong, irqsave/irqrestore
> > assume that "flags" is owned by the caller, not by the lock. And
> > iirc this was certainly wrong in the past.
> >
On 12/23, Linus Torvalds wrote:
>
> On Mon, Dec 23, 2013 at 9:27 AM, Oleg Nesterov wrote:
> >
> > In short, is this code
> >
> > spinlock_t LOCK;
> > unsigned long FLAGS;
> >
> > void my_lock(void)
> >
On 12/23, Oleg Nesterov wrote:
>
> Perhaps we should ask the maintainers upstream? Even if this works, I am
> not sure this is _supposed_ to work. I mean, in theory spin_lock_irqave()
> can be changed as, say
>
> #define spin_lock_irqsave(lock, flags) \
On 12/23, Jason Seba wrote:
>
> Wouldn't the contents of the global flags value be protected by the
> spinlock itself?
This can be even true because nowadays spin_lock_irqsave() writes to
"flags" after it takes the lock, and _irqrestore works gets the copy
of "flags" before it releases the lock.
On 12/23, Tomas Henzl wrote:
>
> On 12/23/2013 04:06 PM, Jack Wang wrote:
> > On 12/23/2013 03:55 PM, Jason Seba wrote:
> >> Why is this considered dangerous? I put some thought into it and
> >> couldn't find any obvious reason why it wouldn't work, but I also
> >> couldn't find any other drivers
On 06/08, Nicholas A. Bellinger wrote:
>
> +unsigned tag_alloc(struct tag_pool *pool, bool wait)
> +{
> + struct tag_cpu_freelist *tags;
> + unsigned long flags;
> + unsigned ret;
> +retry:
> + preempt_disable();
> + local_irq_save(flags);
> + tags = this_cpu_ptr(pool->tag_c
27 matches
Mail list logo
