From: Jiri S. <js...@su...> - 2012-06-04 11:48:46
|
And use count from there. Signed-off-by: Jiri Slaby <js...@su...> Cc: Jeff Dike <jd...@ad...> Cc: Richard Weinberger <ri...@no...> Cc: use...@li... --- 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 |
From: Jiri S. <js...@su...> - 2012-06-04 11:48:46
|
This means switching to the tty refcounted model so that we will not race with interrupts. Signed-off-by: Jiri Slaby <js...@su...> Cc: Jeff Dike <jd...@ad...> Cc: Richard Weinberger <ri...@no...> Cc: use...@li... --- 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 |
From: Richard W. <ri...@no...> - 2012-06-04 12:02:05
Attachments:
signature.asc
|
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 <js...@su...> > Cc: Jeff Dike <jd...@ad...> > Cc: Richard Weinberger <ri...@no...> > Cc: use...@li... > --- > 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; > |
From: Jiri S. <js...@su...> - 2012-06-04 15:20:19
|
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 |
From: Richard W. <ri...@no...> - 2012-06-04 15:29:26
Attachments:
signature.asc
|
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 |
From: Alan C. <al...@lx...> - 2012-06-04 15:55:30
|
> 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 |
From: Jiri S. <js...@su...> - 2012-06-04 15:41:17
|
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 |
From: Richard W. <ri...@no...> - 2012-06-04 15:42:57
Attachments:
signature.asc
|
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 |
From: Boaz H. <bha...@pa...> - 2012-06-04 16:27:38
|
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 > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel |
From: Richard W. <ri...@no...> - 2012-06-04 16:29:25
Attachments:
signature.asc
|
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 |
From: Boaz H. <bha...@pa...> - 2012-06-04 16:37:59
|
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 > |
From: Boaz H. <bha...@pa...> - 2012-06-04 16:55:33
|
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 |
From: Richard W. <ri...@no...> - 2012-06-04 17:05:52
Attachments:
signature.asc
|
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 |
From: Boaz H. <bha...@pa...> - 2012-06-04 17:15:21
|
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 |