(No subject header)

(No subject header)

[Milton Miller]

[Hmm, why did this not appear in patchwork.kernel.org?  Now
I have to guess a CC list.]

On Wed, 26 May 2010 around 22:43:50 -0400 (EDT), Len Brown wrote:
> From: Len Brown <len.brown@intel.com>
> 
> TS_POLLING set tells the scheduler a task will poll
> need_resched() to look for work.
> 

True

> TS_POLLING clear tells resched_task() and wake_up_idle_cpu()
> that the remote CPU is sleeping in idle, and thus requires
> a reschedule interrupt to wake them to notice work.

No, that only applies to the idle task.


> 
> Update the description of TS_POLLING to reflect how it works.
> "cleared when sleeping in idle, requiring reschedule interrupt"

That would imply its set for every normal task that is not in some
kind of sleep state.


> 
> Signed-off-by: Len Brown <len.brown@intel.com>
> Acked-by: Peter Zijlstra <peterz@infradead.org>

> -#define TS_POLLING		0x0004	/* true if in idle loop
> -					   and not sleeping */
> +#define TS_POLLING		0x0004	/* clear when sleeping in idle
> +					   requiring reschedule interrupt */

How about "idle task polling need_resched, skip sending interrupt"?

milton

Re: (No subject header)

[Len Brown]

On Thu, 27 May 2010, Milton Miller wrote:

> 
> [Hmm, why did this not appear in patchwork.kernel.org?  Now
> I have to guess a CC list.]
> 
> On Wed, 26 May 2010 around 22:43:50 -0400 (EDT), Len Brown wrote:
> > From: Len Brown <len.brown@intel.com>
> > 
> > TS_POLLING set tells the scheduler a task will poll
> > need_resched() to look for work.
> > 
> 
> True
> 
> > TS_POLLING clear tells resched_task() and wake_up_idle_cpu()
> > that the remote CPU is sleeping in idle, and thus requires
> > a reschedule interrupt to wake them to notice work.
> 
> No, that only applies to the idle task.
> 
> 
> > 
> > Update the description of TS_POLLING to reflect how it works.
> > "cleared when sleeping in idle, requiring reschedule interrupt"
> 
> That would imply its set for every normal task that is not in some
> kind of sleep state.

you're right, just the idle task sets this flag.

> > Signed-off-by: Len Brown <len.brown@intel.com>
> > Acked-by: Peter Zijlstra <peterz@infradead.org>
> 
> > -#define TS_POLLING		0x0004	/* true if in idle loop
> > -					   and not sleeping */
> > +#define TS_POLLING		0x0004	/* clear when sleeping in idle
> > +					   requiring reschedule interrupt */
> 
> How about "idle task polling need_resched, skip sending interrupt"?

I think that is an improvement over my wording.

Though technically we're not polling need_resched in the case
I have in mind.  The hardware is snooping any write to the thread flags
via MONITOR/MWAIT trigger address.

cheers,
-Len Brown, Intel Open Source Technology Center

Doubt about CRTSCTS preprocessor macro definition in termbits.h file

[Ramya Desai]

Dear All,

I did not understand the CRTSCTS preprocessor macro which is defined
in termbits.h file.

http://lxr.linux.no/linux+v2.6.36/include/asm-generic/termbits.h

As per the typedefs defined in the beginning of the file, the c_cflag
is unsigned int member in the struct termios structure. The CRTSCTS is
defined in the file as a 48 bit value.

#define CRTSCTS   020000000000  /* flow control */

I saw the following snippet in one of the serial applications.

struct termios newtio;
newtio.c_cflag = B9600 | CRTSCTS | CS8 | CLOCAL | CREAD;

My question is, the c_cflag is a 32 bit value member and the CRTSCTS
is a 48 bit value. How CRTSCTS is accommodates into c_cflag variable?
Please let me know, if my interpretation is wrong.

Thanks in advance.

Regards,
Ramya.

(No subject header)

[Milton Miller]

On Tue Nov 09 2010 around 02:27:38 EST, Ramya Desai wrote:
> I did not understand the CRTSCTS preprocessor macro which is defined
> in termbits.h file.
..
> As per the typedefs defined in the beginning of the file, the c_cflag
> is unsigned int member in the struct termios structure. The CRTSCTS is
> defined in the file as a 48 bit value.
> 
> #define CRTSCTS 020000000000 /* flow control */

That is not a 48 bit value.

> 
> I saw the following snippet in one of the serial applications.
> 
> struct termios newtio;
> newtio.c_cflag = B9600 | CRTSCTS | CS8 | CLOCAL | CREAD;
> 
> My question is, the c_cflag is a 32 bit value member and the CRTSCTS
> is a 48 bit value. How CRTSCTS is accommodates into c_cflag variable?
> Please let me know, if my interpretation is wrong.
> 
> Thanks in advance.

Hint: constants in C may be expressed in base 16, 10, or 8.

milton

(No subject header)

[Milton Miller]

On Tue, 30 Nov 2010 about 20:01:29 -0000, Oleg Nesterov wrote:
> Teach get_arg_ptr() to handle compat = T case correctly.

>  #include <asm/uaccess.h>
>  #include <asm/mmu_context.h>
> @@ -395,6 +396,18 @@ get_arg_ptr(const char __user * const __
>  {
>  	const char __user *ptr;
>  
> +#ifdef CONFIG_COMPAT
> +	if (unlikely(compat)) {

This should not be marked unlikely.  Unlikely tells gcc the path
with over 99% confidence and disables branch predictors on some
architectures.  If called from a compat processes this will result
in a mispredicted branch every iteration.  Just use if (compat)
and let the hardware branch predictors do their job.

> +		compat_uptr_t __user *a = (void __user*)argv;
> +		compat_uptr_t p;
> +
> +		if (get_user(p, a + argc))
> +			return ERR_PTR(-EFAULT);
> +
> +		return compat_ptr(p);
> +	}
> +#endif
> +
>  	if (get_user(ptr, argv + argc))
>  		return ERR_PTR(-EFAULT);
>  
> @@ -1501,6 +1514,18 @@ int do_execve(const char *filename,
>  	return do_execve_common(filename, argv, envp, regs, false);
>  }
>  
> +#ifdef CONFIG_COMPAT
> +int compat_do_execve(char * filename,
> +	compat_uptr_t __user *argv,
> +	compat_uptr_t __user *envp,
> +	struct pt_regs * regs)
> +{
> +	return do_execve_common(filename,
> +				(void __user*)argv, (void __user*)envp,

Shouldn't these be compat_ptr(argv)?  (makes a difference on s390)

> +				regs, true);
> +}
> +#endif
> +
>  void set_binfmt(struct linux_binfmt *new)
>  {
>  	struct mm_struct *mm = current->mm;

Thanks,
milton

Re: (No subject header)

[Oleg Nesterov]

On 12/01, Milton Miller wrote:
>
> On Tue, 30 Nov 2010 about 20:01:29 -0000, Oleg Nesterov wrote:
> > Teach get_arg_ptr() to handle compat = T case correctly.
>
> >  #include <asm/uaccess.h>
> >  #include <asm/mmu_context.h>
> > @@ -395,6 +396,18 @@ get_arg_ptr(const char __user * const __
> >  {
> >  	const char __user *ptr;
> >
> > +#ifdef CONFIG_COMPAT
> > +	if (unlikely(compat)) {
>
> This should not be marked unlikely.  Unlikely tells gcc the path
> with over 99% confidence and disables branch predictors on some
> architectures.  If called from a compat processes this will result
> in a mispredicted branch every iteration.  Just use if (compat)
> and let the hardware branch predictors do their job.

This applies to almost every likely/unlikely, and I think that compat
processes should fall into "unlikely category". But I don't really mind,
I can remove this hint, I added it mostly as documentation.

> > +#ifdef CONFIG_COMPAT
> > +int compat_do_execve(char * filename,
> > +	compat_uptr_t __user *argv,
> > +	compat_uptr_t __user *envp,
> > +	struct pt_regs * regs)
> > +{
> > +	return do_execve_common(filename,
> > +				(void __user*)argv, (void __user*)envp,
>
> Shouldn't these be compat_ptr(argv)?  (makes a difference on s390)

I'll recheck, but I don't think so. Please note that compat_ptr()
accepts "compat_uptr_t", not "compat_uptr_t *".

argv should be correct as a pointer to user-space, otherwise the
current code is buggy. For example, compat_do_execve() passes
argv to compat_count() which does get_user(argv) without any
conversion.

IOW, even if this should be fixed, I think this have nothing to
do with this patch. But I'll recheck, thanks.

Oleg.

(No subject header)

[gina]

You have just won £1,000,000GBP.Please Contact your Claims
Personnel with your email only to. nellydave1@gmail.com .for
info
......................................................................
NOTE : If You Recieve This Message In Your
Junk Or Spam Its Due To Your Internet
Provider.