linux-kernel - Re: [RFC 2.6.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Dec 2006 18:54:05 -0500
From:	"Jaya Kumar" <jayakumar.lkml@...il.com>
To:	Franck <vagabon.xyz@...il.com>
Cc:	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC 2.6.19 1/1] fbdev,mm: hecuba/E-Ink fbdev driver v2

On 12/11/06, Franck Bui-Huu <vagabon.xyz@...il.com> wrote:
> jayakumar.lkml@...il.com wrote:
> > +     atomic_t ref_count;
> > +     atomic_t vma_count;
>
> what purpose do these counters deserve ?

You are right. I can remove them.

> > +
> > +void hcb_wait_for_ack(struct hecubafb_par *par)
> > +{
> > +
> > +     int timeout;
> > +     unsigned char ctl;
> > +
> > +     timeout=500;
> > +     do {
> > +             ctl = hcb_get_ctl(par);
> > +             if ((ctl & HCB_ACK_BIT))
> > +                     return;
> > +             udelay(1);
> > +     } while (timeout--);
> > +     printk(KERN_ERR "timed out waiting for ack\n");
> > +}
>
> When timeout occur this function does not return any error values.
> the callers needn't to be warn in this case ?

You are right. I need to figure out what exactly to do. Currently, if
a timeout is observed it normally means the display controller is
hung. However, in some cases  the controller does seem to recover
after some period of time. I guess I should probably return an error
and terminate pending activity.

> > +
> > +/* this is to find and return the vmalloc-ed fb pages */
> > +static struct page* hecubafb_vm_nopage(struct vm_area_struct *vma,
> > +                                     unsigned long vaddr, int *type)
> > +{
> > +     unsigned long offset;
> > +     struct page *page;
> > +     struct fb_info *info = vma->vm_private_data;
> > +
> > +     offset = (vaddr - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
> > +     if (offset >= (DPY_W*DPY_H)/8)
> > +             return NOPAGE_SIGBUS;
> > +
> > +     page = vmalloc_to_page(info->screen_base + offset);
> > +     if (!page)
> > +             return NOPAGE_OOM;
> > +
> > +     get_page(page);
> > +     if (type)
> > +             *type = VM_FAULT_MINOR;
> > +     return page;
> > +}
> > +
>
> so page can be accessed by using vma->start virtual address....

The userspace app would be doing:

ioctl(fd, FBIOGET_FSCREENINFO, &finfo);
ioctl(fd, FBIOGET_VSCREENINFO, &vinfo);
screensize = ( vinfo.xres * vinfo.yres * vinfo.bits_per_pixel) / 8;
maddr = mmap(finfo.mmio_start, screensize, PROT_WRITE, MAP_SHARED, fd, 0);

>
> > +static int hecubafb_page_mkwrite(struct vm_area_struct *vma,
>
> [snip]
>
> > +
> > +     if (!(videomemory = vmalloc(videomemorysize)))
> > +             return retval;
>
> and here the kernel access to the same page by using address returned
> by vmalloc which are different from the previous one. So 2 different
> addresses map the same physical page. In this case are there any cache
> aliasing issues specially for x86 arch ?

I think that PTEs set up by vmalloc are marked cacheable and via the
above nopage end up as cacheable. I'm not doing DMA. So the accesses
are through the cache so I don't think cache aliasing is an issue for
this case. Please let me know if I misunderstood.

Thanks,
jayakumar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/