[PATCH 12/24] TTY: um/line, add tty_port

[PATCH 12/24] TTY: um/line, add tty_port

[Jiri Slaby]

And use count from there.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: user-mode-linux-devel@lists.sourceforge.net
---
 arch/um/drivers/line.c |    7 ++++---
 arch/um/drivers/line.h |    2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
index acfd0e0..482a7bd 100644
--- a/arch/um/drivers/line.c
+++ b/arch/um/drivers/line.c
@@ -404,7 +404,7 @@ int line_open(struct line *lines, struct tty_struct *tty)
 		goto out_unlock;
 
 	err = 0;
-	if (line->count++)
+	if (line->port.count++)
 		goto out_unlock;
 
 	BUG_ON(tty->driver_data);
@@ -446,7 +446,7 @@ void line_close(struct tty_struct *tty, struct file * filp)
 	mutex_lock(&line->count_lock);
 	BUG_ON(!line->valid);
 
-	if (--line->count)
+	if (--line->port.count)
 		goto out_unlock;
 
 	line->tty = NULL;
@@ -478,7 +478,7 @@ int setup_one_line(struct line *lines, int n, char *init,
 
 	mutex_lock(&line->count_lock);
 
-	if (line->count) {
+	if (line->port.count) {
 		*error_out = "Device is already open";
 		goto out;
 	}
@@ -663,6 +663,7 @@ int register_lines(struct line_driver *line_driver,
 	driver->init_termios = tty_std_termios;
 	
 	for (i = 0; i < nlines; i++) {
+		tty_port_init(&lines[i].port);
 		spin_lock_init(&lines[i].lock);
 		mutex_init(&lines[i].count_lock);
 		lines[i].driver = line_driver;
diff --git a/arch/um/drivers/line.h b/arch/um/drivers/line.h
index 0a18347..0e06a1f 100644
--- a/arch/um/drivers/line.h
+++ b/arch/um/drivers/line.h
@@ -32,9 +32,9 @@ struct line_driver {
 };
 
 struct line {
+	struct tty_port port;
 	struct tty_struct *tty;
 	struct mutex count_lock;
-	unsigned long count;
 	int valid;
 
 	char *init_str;
-- 
1.7.10.3

[PATCH 13/24] TTY: um/line, use tty from tty_port

[Jiri Slaby]

This means switching to the tty refcounted model so that we will not
race with interrupts.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: user-mode-linux-devel@lists.sourceforge.net
---
 arch/um/drivers/chan_kern.c |    4 +++-
 arch/um/drivers/line.c      |   25 ++++++++++++++++++-------
 arch/um/drivers/line.h      |    1 -
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/arch/um/drivers/chan_kern.c b/arch/um/drivers/chan_kern.c
index 45e248c..87eebfe 100644
--- a/arch/um/drivers/chan_kern.c
+++ b/arch/um/drivers/chan_kern.c
@@ -150,9 +150,11 @@ void chan_enable_winch(struct chan *chan, struct tty_struct *tty)
 static void line_timer_cb(struct work_struct *work)
 {
 	struct line *line = container_of(work, struct line, task.work);
+	struct tty_struct *tty = tty_port_tty_get(&line->port);
 
 	if (!line->throttled)
-		chan_interrupt(line, line->tty, line->driver->read_irq);
+		chan_interrupt(line, tty, line->driver->read_irq);
+	tty_kref_put(tty);
 }
 
 int enable_chan(struct line *line)
diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
index 482a7bd..fb6e4ea 100644
--- a/arch/um/drivers/line.c
+++ b/arch/um/drivers/line.c
@@ -19,9 +19,11 @@ static irqreturn_t line_interrupt(int irq, void *data)
 {
 	struct chan *chan = data;
 	struct line *line = chan->line;
+	struct tty_struct *tty = tty_port_tty_get(&line->port);
 
 	if (line)
-		chan_interrupt(line, line->tty, irq);
+		chan_interrupt(line, tty, irq);
+	tty_kref_put(tty);
 	return IRQ_HANDLED;
 }
 
@@ -333,7 +335,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
 {
 	struct chan *chan = data;
 	struct line *line = chan->line;
-	struct tty_struct *tty = line->tty;
+	struct tty_struct *tty;
 	int err;
 
 	/*
@@ -352,10 +354,13 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
 	}
 	spin_unlock(&line->lock);
 
+	tty = tty_port_tty_get(&line->port);
 	if (tty == NULL)
 		return IRQ_NONE;
 
 	tty_wakeup(tty);
+	tty_kref_put(tty);
+
 	return IRQ_HANDLED;
 }
 
@@ -409,7 +414,7 @@ int line_open(struct line *lines, struct tty_struct *tty)
 
 	BUG_ON(tty->driver_data);
 	tty->driver_data = line;
-	line->tty = tty;
+	tty_port_tty_set(&line->port, tty);
 
 	err = enable_chan(line);
 	if (err) /* line_close() will be called by our caller */
@@ -449,7 +454,7 @@ void line_close(struct tty_struct *tty, struct file * filp)
 	if (--line->port.count)
 		goto out_unlock;
 
-	line->tty = NULL;
+	tty_port_tty_set(&line->port, NULL);
 	tty->driver_data = NULL;
 
 	if (line->sigio) {
@@ -610,9 +615,15 @@ int line_get_config(char *name, struct line *lines, unsigned int num, char *str,
 	mutex_lock(&line->count_lock);
 	if (!line->valid)
 		CONFIG_CHUNK(str, size, n, "none", 1);
-	else if (line->tty == NULL)
-		CONFIG_CHUNK(str, size, n, line->init_str, 1);
-	else n = chan_config_string(line, str, size, error_out);
+	else {
+		struct tty_struct *tty = tty_port_tty_get(&line->port);
+		if (tty == NULL) {
+			CONFIG_CHUNK(str, size, n, line->init_str, 1);
+		} else {
+			n = chan_config_string(line, str, size, error_out);
+			tty_kref_put(tty);
+		}
+	}
 	mutex_unlock(&line->count_lock);
 
 	return n;
diff --git a/arch/um/drivers/line.h b/arch/um/drivers/line.h
index 0e06a1f..5b3d4fb 100644
--- a/arch/um/drivers/line.h
+++ b/arch/um/drivers/line.h
@@ -33,7 +33,6 @@ struct line_driver {
 
 struct line {
 	struct tty_port port;
-	struct tty_struct *tty;
 	struct mutex count_lock;
 	int valid;
 
-- 
1.7.10.3

Re: [PATCH 13/24] TTY: um/line, use tty from tty_port

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 4244 bytes --]

Jiri,

Thanks a lot for fixing this!

I have two questions:
1. Are these patches also usable on 3.4 and 3.3 or do they depend on 3.5's TTY changes?
2. Why didn't you use tty_port_open()/close()/etc. as Alan suggested my in [1]?

Thanks,
//richard

[1] http://lkml.indiana.edu/hypermail/linux/kernel/1201.3/01705.html

Am 04.06.2012 13:35, schrieb Jiri Slaby:
> This means switching to the tty refcounted model so that we will not
> race with interrupts.
> 
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: Jeff Dike <jdike@addtoit.com>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: user-mode-linux-devel@lists.sourceforge.net
> ---
>  arch/um/drivers/chan_kern.c |    4 +++-
>  arch/um/drivers/line.c      |   25 ++++++++++++++++++-------
>  arch/um/drivers/line.h      |    1 -
>  3 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/um/drivers/chan_kern.c b/arch/um/drivers/chan_kern.c
> index 45e248c..87eebfe 100644
> --- a/arch/um/drivers/chan_kern.c
> +++ b/arch/um/drivers/chan_kern.c
> @@ -150,9 +150,11 @@ void chan_enable_winch(struct chan *chan, struct tty_struct *tty)
>  static void line_timer_cb(struct work_struct *work)
>  {
>  	struct line *line = container_of(work, struct line, task.work);
> +	struct tty_struct *tty = tty_port_tty_get(&line->port);
>  
>  	if (!line->throttled)
> -		chan_interrupt(line, line->tty, line->driver->read_irq);
> +		chan_interrupt(line, tty, line->driver->read_irq);
> +	tty_kref_put(tty);
>  }
>  
>  int enable_chan(struct line *line)
> diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
> index 482a7bd..fb6e4ea 100644
> --- a/arch/um/drivers/line.c
> +++ b/arch/um/drivers/line.c
> @@ -19,9 +19,11 @@ static irqreturn_t line_interrupt(int irq, void *data)
>  {
>  	struct chan *chan = data;
>  	struct line *line = chan->line;
> +	struct tty_struct *tty = tty_port_tty_get(&line->port);
>  
>  	if (line)
> -		chan_interrupt(line, line->tty, irq);
> +		chan_interrupt(line, tty, irq);
> +	tty_kref_put(tty);
>  	return IRQ_HANDLED;
>  }
>  
> @@ -333,7 +335,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>  {
>  	struct chan *chan = data;
>  	struct line *line = chan->line;
> -	struct tty_struct *tty = line->tty;
> +	struct tty_struct *tty;
>  	int err;
>  
>  	/*
> @@ -352,10 +354,13 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
>  	}
>  	spin_unlock(&line->lock);
>  
> +	tty = tty_port_tty_get(&line->port);
>  	if (tty == NULL)
>  		return IRQ_NONE;
>  
>  	tty_wakeup(tty);
> +	tty_kref_put(tty);
> +
>  	return IRQ_HANDLED;
>  }
>  
> @@ -409,7 +414,7 @@ int line_open(struct line *lines, struct tty_struct *tty)
>  
>  	BUG_ON(tty->driver_data);
>  	tty->driver_data = line;
> -	line->tty = tty;
> +	tty_port_tty_set(&line->port, tty);
>  
>  	err = enable_chan(line);
>  	if (err) /* line_close() will be called by our caller */
> @@ -449,7 +454,7 @@ void line_close(struct tty_struct *tty, struct file * filp)
>  	if (--line->port.count)
>  		goto out_unlock;
>  
> -	line->tty = NULL;
> +	tty_port_tty_set(&line->port, NULL);
>  	tty->driver_data = NULL;
>  
>  	if (line->sigio) {
> @@ -610,9 +615,15 @@ int line_get_config(char *name, struct line *lines, unsigned int num, char *str,
>  	mutex_lock(&line->count_lock);
>  	if (!line->valid)
>  		CONFIG_CHUNK(str, size, n, "none", 1);
> -	else if (line->tty == NULL)
> -		CONFIG_CHUNK(str, size, n, line->init_str, 1);
> -	else n = chan_config_string(line, str, size, error_out);
> +	else {
> +		struct tty_struct *tty = tty_port_tty_get(&line->port);
> +		if (tty == NULL) {
> +			CONFIG_CHUNK(str, size, n, line->init_str, 1);
> +		} else {
> +			n = chan_config_string(line, str, size, error_out);
> +			tty_kref_put(tty);
> +		}
> +	}
>  	mutex_unlock(&line->count_lock);
>  
>  	return n;
> diff --git a/arch/um/drivers/line.h b/arch/um/drivers/line.h
> index 0e06a1f..5b3d4fb 100644
> --- a/arch/um/drivers/line.h
> +++ b/arch/um/drivers/line.h
> @@ -33,7 +33,6 @@ struct line_driver {
>  
>  struct line {
>  	struct tty_port port;
> -	struct tty_struct *tty;
>  	struct mutex count_lock;
>  	int valid;
>  



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [PATCH 13/24] TTY: um/line, use tty from tty_port

[Jiri Slaby]

On 06/04/2012 02:01 PM, Richard Weinberger wrote:
> I have two questions: 1. Are these patches also usable on 3.4 and
> 3.3 or do they depend on 3.5's TTY changes?

Hi, I don't think they depend on any changes.

> 2. Why didn't you use tty_port_open()/close()/etc. as Alan
> suggested my in [1]?

This was not intended to fix anything particular. If it does, it is a
pure coincidence... These patches are a minimalistic subset to ensure
every driver has its own tty_port for each tty. We will need this
pairing later.

So the switch of the driver to the new tty port API, as suggested by
Alan, is still needed. I might do that later if I learn how to make
UML work. (The conversion is by definition invasive and needs runtime
testing.)

> [1]
> http://lkml.indiana.edu/hypermail/linux/kernel/1201.3/01705.html

thanks,
-- 
js
suse labs

Re: [PATCH 13/24] TTY: um/line, use tty from tty_port

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

Hi!

Am 04.06.2012 17:20, schrieb Jiri Slaby:
> On 06/04/2012 02:01 PM, Richard Weinberger wrote:
>> I have two questions: 1. Are these patches also usable on 3.4 and
>> 3.3 or do they depend on 3.5's TTY changes?
> 
> Hi, I don't think they depend on any changes.

Nice.

>> 2. Why didn't you use tty_port_open()/close()/etc. as Alan
>> suggested my in [1]?
> 
> This was not intended to fix anything particular. If it does, it is a
> pure coincidence... These patches are a minimalistic subset to ensure
> every driver has its own tty_port for each tty. We will need this
> pairing later.

It looks like that it solves UML's TTY issues with systemd distros. :-)

> So the switch of the driver to the new tty port API, as suggested by
> Alan, is still needed. I might do that later if I learn how to make
> UML work. (The conversion is by definition invasive and needs runtime
> testing.)

Two days ago I did so but still faced the problems described here:
https://lkml.org/lkml/2012/3/10/163

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [PATCH 13/24] TTY: um/line, use tty from tty_port

[Jiri Slaby]

On 06/04/2012 05:29 PM, Richard Weinberger wrote:
> It looks like that it solves UML's TTY issues with systemd distros.
> :-)

Good.

>> So the switch of the driver to the new tty port API, as suggested
>> by Alan, is still needed. I might do that later if I learn how to
>> make UML work. (The conversion is by definition invasive and
>> needs runtime testing.)
> 
> Two days ago I did so but still faced the problems described here: 
> https://lkml.org/lkml/2012/3/10/163

Hmm, I remember. I suggest you to split the patch into several pieces.
For example moving the code from ->open into ->install can be done
separately. Otherwise it's hard to tell what's wrong with the patch as
a whole.

Also, it would be good to see the patch rebased on the top of my
patch, because tty_port_set/get pieces would be gone from your patch too.

regards,
-- 
js
suse labs

Re: [PATCH 13/24] TTY: um/line, use tty from tty_port

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

Am 04.06.2012 17:41, schrieb Jiri Slaby:
> Hmm, I remember. I suggest you to split the patch into several pieces.
> For example moving the code from ->open into ->install can be done
> separately. Otherwise it's hard to tell what's wrong with the patch as
> a whole.
> 
> Also, it would be good to see the patch rebased on the top of my
> patch, because tty_port_set/get pieces would be gone from your patch too.

Okay, I'll redo it!
I've a much cleaner version in my local queue.

Thanks,
//richard



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [uml-devel] [PATCH 13/24] TTY: um/line, use tty from tty_port

[Alan Cox]

> Two days ago I did so but still faced the problems described here:
> https://lkml.org/lkml/2012/3/10/163

If you are running a Fedora like distro it's because the user space is
broken. At some point we are going to have to make them fix the userspace
not to sit with ttys held open.


Alan

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 13/24] TTY: um/line, use tty from tty_port

[Boaz Harrosh]

On 06/04/2012 06:42 PM, Richard Weinberger wrote:

> Am 04.06.2012 17:41, schrieb Jiri Slaby:
>> Hmm, I remember. I suggest you to split the patch into several pieces.
>> For example moving the code from ->open into ->install can be done
>> separately. Otherwise it's hard to tell what's wrong with the patch as
>> a whole.
>>
>> Also, it would be good to see the patch rebased on the top of my
>> patch, because tty_port_set/get pieces would be gone from your patch too.
> 
> Okay, I'll redo it!
> I've a much cleaner version in my local queue.
> 


Can you send it my way, I'm still running broken, 3.4 Based ?

Thanks very much in advance
Boaz

> Thanks,
> //richard
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 
> 
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> User-mode-linux-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 13/24] TTY: um/line, use tty from tty_port

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

Am 04.06.2012 18:27, schrieb Boaz Harrosh:
> On 06/04/2012 06:42 PM, Richard Weinberger wrote:
> 
>> Am 04.06.2012 17:41, schrieb Jiri Slaby:
>>> Hmm, I remember. I suggest you to split the patch into several pieces.
>>> For example moving the code from ->open into ->install can be done
>>> separately. Otherwise it's hard to tell what's wrong with the patch as
>>> a whole.
>>>
>>> Also, it would be good to see the patch rebased on the top of my
>>> patch, because tty_port_set/get pieces would be gone from your patch too.
>>
>> Okay, I'll redo it!
>> I've a much cleaner version in my local queue.
>>
> 
> 
> Can you send it my way, I'm still running broken, 3.4 Based ?
> 

Can you please first give Jiri's patches a try?

[PATCH 12/24] TTY: um/line, add tty_port
[PATCH 13/24] TTY: um/line, use tty from tty_port

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [uml-devel] [PATCH 13/24] TTY: um/line, use tty from tty_port

[Boaz Harrosh]

On 06/04/2012 07:29 PM, Richard Weinberger wrote:

> Am 04.06.2012 18:27, schrieb Boaz Harrosh:
>> On 06/04/2012 06:42 PM, Richard Weinberger wrote:
>>
>>> Am 04.06.2012 17:41, schrieb Jiri Slaby:
>>>> Hmm, I remember. I suggest you to split the patch into several pieces.
>>>> For example moving the code from ->open into ->install can be done
>>>> separately. Otherwise it's hard to tell what's wrong with the patch as
>>>> a whole.
>>>>
>>>> Also, it would be good to see the patch rebased on the top of my
>>>> patch, because tty_port_set/get pieces would be gone from your patch too.
>>>
>>> Okay, I'll redo it!
>>> I've a much cleaner version in my local queue.
>>>
>>
>>
>> Can you send it my way, I'm still running broken, 3.4 Based ?
>>
> 
> Can you please first give Jiri's patches a try?
> 
> [PATCH 12/24] TTY: um/line, add tty_port
> [PATCH 13/24] TTY: um/line, use tty from tty_port
> 


OK Will do

Boaz

> Thanks,
> //richard
> 



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 13/24] TTY: um/line, use tty from tty_port

[Boaz Harrosh]

On 06/04/2012 07:29 PM, Richard Weinberger wrote:

> Am 04.06.2012 18:27, schrieb Boaz Harrosh:
>> On 06/04/2012 06:42 PM, Richard Weinberger wrote:
>>
>>> Am 04.06.2012 17:41, schrieb Jiri Slaby:
>>>> Hmm, I remember. I suggest you to split the patch into several pieces.
>>>> For example moving the code from ->open into ->install can be done
>>>> separately. Otherwise it's hard to tell what's wrong with the patch as
>>>> a whole.
>>>>
>>>> Also, it would be good to see the patch rebased on the top of my
>>>> patch, because tty_port_set/get pieces would be gone from your patch too.
>>>
>>> Okay, I'll redo it!
>>> I've a much cleaner version in my local queue.
>>>
>>
>>
>> Can you send it my way, I'm still running broken, 3.4 Based ?
>>
> 
> Can you please first give Jiri's patches a try?
> 
> [PATCH 12/24] TTY: um/line, add tty_port
> [PATCH 13/24] TTY: um/line, use tty from tty_port
> 


No still crashing the same, way. BTW I do not have a systemd Distro. It's
plain old FC12. Though in the lab I have the same crash with FC15.

The crash is immediately after I login at the initial prompt. (every time)

Here is the crash print, what ever that is worth in UML.
(Can we make the crash dump stack trace a bit less terrible?)

----
Modules linked in: nfsd nfs lockd auth_rpcgss nfs_acl sunrpc osd libosd ipv6 binfmt_misc [last unloaded: scsi_wait_scan]
Pid: 1243, comm: login Not tainted 3.4.0-pnfs+
RIP: 0033:[<00000000601bbf7f>]
RSP: 0000000077ed7ad0  EFLAGS: 00010202
RAX: 00000000601bbf6b RBX: 00000000000001d8 RCX: 000000000000000b
RDX: 00000000600206dc RSI: 00000000601c4c14 RDI: 00000000000001d8
RBP: 0000000077ed7b20 R08: 0000000000000000 R09: 0000000077ed7c30
R10: 0000000000000000 R11: 0000003ea3882a83 R12: 0000000000000000
R13: 0000000000000fff R14: 0000000000000002 R15: 0000000077ed7c30
Call Trace: 
603556c8:  [<6001c6ac>] segv+0x2f6/0x31c
603556e0:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
60355708:  [<6007d89f>] rcu_sched_qs+0xb8/0xbc
60355740:  [<600191c8>] do_IRQ+0x0/0x54
60355748:  [<6002bdf3>] os_waiting_for_events+0x0/0xb9
603557a8:  [<60018d98>] to_irq_stack+0x0/0xa1
603557b8:  [<6001c75e>] segv_handler+0x8c/0x96
603557d8:  [<600194c9>] sigio_handler+0x88/0x93
60355808:  [<6002d733>] sig_handler_common+0x9f/0xb3
60355860:  [<601bbf6b>] do_raw_spin_lock+0x0/0x121
60355870:  [<600206dc>] line_chars_in_buffer+0x0/0x82
60355878:  [<601c4c14>] tty_chars_in_buffer+0x0/0x17
60355890:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
603558b0:  [<601b331d>] radix_tree_lookup_slot+0x4d/0x5c
60355920:  [<6001669c>] _einittext+0x18d1/0x2b55
60355930:  [<600161a8>] _einittext+0x13dd/0x2b55
60355a08:  [<6001669c>] _einittext+0x18d1/0x2b55
60355aa0:  [<60017e28>] _init+0x508/0x870
60355aa8:  [<60018d98>] to_irq_stack+0x0/0xa1
60355b28:  [<60017e28>] _init+0x508/0x870
60355b38:  [<6002d906>] sig_handler+0x4c/0x5e
60355b58:  [<6002db99>] hard_handler+0x89/0xcb
60355c30:  [<601c4c14>] tty_chars_in_buffer+0x0/0x17
60355c48:  [<600206dc>] line_chars_in_buffer+0x0/0x82
60355c50:  [<601bbf6b>] do_raw_spin_lock+0x0/0x121
60355c68:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121

Kernel panic - not syncing: Kernel mode fault at addr 0x1dc, ip 0x601bbf7f
Call Trace: 
603555b8:  [<60280af4>] panic+0x170/0x2e0
603555f0:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
603555f8:  [<60280984>] panic+0x0/0x2e0
60355610:  [<6006d5fd>] __module_text_address+0x14/0x5a
60355628:  [<6006d653>] is_module_text_address+0x10/0x18
60355638:  [<60050ced>] __kernel_text_address+0x97/0x9d
60355640:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
60355658:  [<6001afc0>] show_trace+0xd4/0xdf
603556c8:  [<6001c6d2>] segv_handler+0x0/0x96
603556e0:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
60355708:  [<6007d89f>] rcu_sched_qs+0xb8/0xbc
60355740:  [<600191c8>] do_IRQ+0x0/0x54
60355748:  [<6002bdf3>] os_waiting_for_events+0x0/0xb9
603557a8:  [<60018d98>] to_irq_stack+0x0/0xa1
603557b8:  [<6001c75e>] segv_handler+0x8c/0x96
603557d8:  [<600194c9>] sigio_handler+0x88/0x93
60355808:  [<6002d733>] sig_handler_common+0x9f/0xb3
60355860:  [<601bbf6b>] do_raw_spin_lock+0x0/0x121
60355870:  [<600206dc>] line_chars_in_buffer+0x0/0x82
60355878:  [<601c4c14>] tty_chars_in_buffer+0x0/0x17
60355890:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
603558b0:  [<601b331d>] radix_tree_lookup_slot+0x4d/0x5c
60355920:  [<6001669c>] _einittext+0x18d1/0x2b55
60355930:  [<600161a8>] _einittext+0x13dd/0x2b55
60355a08:  [<6001669c>] _einittext+0x18d1/0x2b55
60355aa0:  [<60017e28>] _init+0x508/0x870
60355aa8:  [<60018d98>] to_irq_stack+0x0/0xa1
60355b28:  [<60017e28>] _init+0x508/0x870
60355b38:  [<6002d906>] sig_handler+0x4c/0x5e
60355b58:  [<6002db99>] hard_handler+0x89/0xcb
60355c30:  [<601c4c14>] tty_chars_in_buffer+0x0/0x17
60355c48:  [<600206dc>] line_chars_in_buffer+0x0/0x82
60355c50:  [<601bbf6b>] do_raw_spin_lock+0x0/0x121
60355c68:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121


Modules linked in: nfsd nfs lockd auth_rpcgss nfs_acl sunrpc osd libosd ipv6 binfmt_misc [last unloaded: scsi_wait_scan]
Pid: 1243, comm: login Not tainted 3.4.0-pnfs+
RIP: 0033:[<00000030914d8318>]
RSP: 0000007fbfe72740  EFLAGS: 00000202
RAX: ffffffffffffffda RBX: 0000000000000010 RCX: ffffffffffffffff
RDX: 0000007fbfe72710 RSI: 0000000000005404 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000007fbfe74c40 R09: 0000000000000000
R10: 0000007fbfe72710 R11: 0000000000000202 R12: 0000007fbfe74c40
R13: 0000007fbfe72ac7 R14: 0000007fbfe72a50 R15: 0000000000000000
Call Trace: 
60355538:  [<6001c8c5>] panic_exit+0x3e/0x5c
60355540:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
60355568:  [<60058a76>] notifier_call_chain+0x32/0x5e
603555a8:  [<60058ad2>] atomic_notifier_call_chain+0x1a/0x1c
603555b8:  [<60280b24>] panic+0x1a0/0x2e0
603555f0:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
603555f8:  [<60280984>] panic+0x0/0x2e0
60355610:  [<6006d5fd>] __module_text_address+0x14/0x5a
60355628:  [<6006d653>] is_module_text_address+0x10/0x18
60355638:  [<60050ced>] __kernel_text_address+0x97/0x9d
60355640:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
60355658:  [<6001afc0>] show_trace+0xd4/0xdf
603556c8:  [<6001c6d2>] segv_handler+0x0/0x96
603556e0:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
60355708:  [<6007d89f>] rcu_sched_qs+0xb8/0xbc
60355740:  [<600191c8>] do_IRQ+0x0/0x54
60355748:  [<6002bdf3>] os_waiting_for_events+0x0/0xb9
603557a8:  [<60018d98>] to_irq_stack+0x0/0xa1
603557b8:  [<6001c75e>] segv_handler+0x8c/0x96
603557d8:  [<600194c9>] sigio_handler+0x88/0x93
60355808:  [<6002d733>] sig_handler_common+0x9f/0xb3
60355860:  [<601bbf6b>] do_raw_spin_lock+0x0/0x121
60355870:  [<600206dc>] line_chars_in_buffer+0x0/0x82
60355878:  [<601c4c14>] tty_chars_in_buffer+0x0/0x17
60355890:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
603558b0:  [<601b331d>] radix_tree_lookup_slot+0x4d/0x5c
60355920:  [<6001669c>] _einittext+0x18d1/0x2b55
60355930:  [<600161a8>] _einittext+0x13dd/0x2b55
60355a08:  [<6001669c>] _einittext+0x18d1/0x2b55
60355aa0:  [<60017e28>] _init+0x508/0x870
60355aa8:  [<60018d98>] to_irq_stack+0x0/0xa1
60355b28:  [<60017e28>] _init+0x508/0x870
60355b38:  [<6002d906>] sig_handler+0x4c/0x5e
60355b58:  [<6002db99>] hard_handler+0x89/0xcb
60355c30:  [<601c4c14>] tty_chars_in_buffer+0x0/0x17
60355c48:  [<600206dc>] line_chars_in_buffer+0x0/0x82
60355c50:  [<601bbf6b>] do_raw_spin_lock+0x0/0x121
60355c68:  [<601bbf7f>] do_raw_spin_lock+0x14/0x121
----

BTW I suspect that UML is unable to catch an invalid pointer execution
and just dumps core and exits. Let me explain.

A:
	foo == ((foo_t *)NULL)->member_not_first
 A NULL access backtrace will be generated before UML exit

but ..
B: a function call
	((foo_op *)NULL)->function_member_not_first(...);

 Will crap out without any kind of stack trace.

Is that possible?

Thanks
Boaz

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH 13/24] TTY: um/line, use tty from tty_port

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

Am 04.06.2012 18:55, schrieb Boaz Harrosh:
> No still crashing the same, way. BTW I do not have a systemd Distro. It's
> plain old FC12. Though in the lab I have the same crash with FC15.
> 
> The crash is immediately after I login at the initial prompt. (every time)

Okay, I'll test my patches with FC12 too. :-\

> Here is the crash print, what ever that is worth in UML.
> (Can we make the crash dump stack trace a bit less terrible?)

-ENOPATCH. :-)
Feel free to send one.

Thanks,
//richard



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [uml-devel] [PATCH 13/24] TTY: um/line, use tty from tty_port

[Boaz Harrosh]

On 06/04/2012 08:05 PM, Richard Weinberger wrote:

> Am 04.06.2012 18:55, schrieb Boaz Harrosh:
>> No still crashing the same, way. BTW I do not have a systemd Distro. It's
>> plain old FC12. Though in the lab I have the same crash with FC15.
>>
>> The crash is immediately after I login at the initial prompt. (every time)
> 
> Okay, I'll test my patches with FC12 too. :-\
> 


Thanks. Do you need help with an image?

>> Here is the crash print, what ever that is worth in UML.
>> (Can we make the crash dump stack trace a bit less terrible?)
> 
> -ENOPATCH. :-)
> Feel free to send one.
> 


:-) It's always the: "how much time I spend on saving time later?"

But I promise I'll do it one day.

> Thanks,
> //richard
> 
> 


Thanks
Boaz

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel