All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rick L. Vinyard, Jr." <rvinyard@cs.nmsu.edu>
To: "Oliver Neukum" <oliver@neukum.org>
Cc: "Bruno Prémont" <bonbons@linux-vserver.org>,
	"Jiri Kosina" <jkosina@suse.cz>,
	linux-input@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Nicu Pavel" <npavel@ituner.com>
Subject: Re: [PATCH 1/3] picolcd: driver for PicoLCD HID device
Date: Wed, 24 Feb 2010 14:44:53 -0700	[thread overview]
Message-ID: <ffb352764fc5a0da5cca6f3da7fc2603.squirrel@intranet.cs.nmsu.edu> (raw)
In-Reply-To: <201002241927.53532.oliver@neukum.org>


Oliver Neukum wrote:
> Am Mittwoch, 24. Februar 2010 17:00:49 schrieb Bruno Prémont:
>> +static int picolcd_raw_event(struct hid_device *hdev,
>> +               struct hid_report *report, u8 *raw_data, int size)
>> +{
>> +       struct picolcd_data *data = hid_get_drvdata(hdev);
>> +       char hexdata[25];
>> +       int i;
>> +
>> +       if (data == NULL)
>> +               return 1;
>> +
>> +       for (i = 0; i < sizeof(hexdata) / 2; i++)
>> +               sprintf(hexdata+2*i, "%02hhx", raw_data[i]);
>> +       if (size >= sizeof(hexdata)/2) {
>> +               hexdata[sizeof(hexdata)-4] = '.';
>> +               hexdata[sizeof(hexdata)-3] = '.';
>> +               hexdata[sizeof(hexdata)-2] = '.';
>> +               hexdata[sizeof(hexdata)-1] = '\0';
>> +       } else
>> +               hexdata[size*2] = '\0';
>> +
>> +       switch (report->id) {
>> +       case REPORT_KEYPAD:
>> +               if (size == 3 && raw_data[0] == 0x11 &&
>> data->input_keys) {
>> +                       return picolcd_raw_keypad(hdev, report,
>> raw_data+1, size-1);
>> +               } else {
>> +                       dbg_hid(PICOLCD_NAME " unsupported key event (%d
>> bytes): 0x%s\n", size, hexdata);
>> +                       break;
>> +               }
>> +               break;
>> +       case REPORT_VERSION:
>> +               if (size == 3)
>> +                       dev_info(&hdev->dev, "Firmware version is
>> %hd.%hd\n", raw_data[1], raw_data[2]);
>> +
>> +               spin_lock(&data->lock);
>
> If I recall correctly raw_event is called in interrupt. As you take a
> spinlock here,
> the lock in code not called in interrupt must disable interrupts, or you
> may
> deadlock.
>

The issue, as I understand it is that non-interrupt code may obtain the
lock and then the interrupt code is executed... hence the deadlock and the
need to use spin_lock_irqsave() and spin_unlock_irqrestore().

If that is correct, is there any problem with the following approach?

The key difference is the replacement of spin_lock() with spin_trylock()
such that if the non-interrupt code has already obtained the lock, the
interrupt will not deadlock but instead take the else path and schedule a
framebuffer update at the next interval.

static void g13_fb_urb_completion(struct urb *urb)
{
	struct g13_data *data = urb->context;
	spin_unlock(&data->fb_urb_lock);
}

static int g13_fb_send(struct hid_device *hdev)
{
	struct usb_interface *intf;
	struct usb_device *usb_dev;
	struct g13_data *data = hid_get_g13data(hdev);

	struct usb_host_endpoint *ep;
	unsigned int pipe;
	int retval = 0;

	/*
	 * Try and lock the framebuffer urb to prevent access if we have
	 * submitted it. If we can't lock it we'll have to delay this update
	 * until the next framebuffer interval.
	 *
	 * Fortunately, we already have the infrastructure in place with the
	 * framebuffer deferred I/O driver to schedule the delayed update.
	 */
	if (likely(spin_trylock(&data->fb_urb_lock))) {
		/* Get the usb device to send the image on */
		intf = to_usb_interface(hdev->dev.parent);
		usb_dev = interface_to_usbdev(intf);

		pipe = usb_sndintpipe(usb_dev, 0x02);

		ep = usb_dev->ep_out[usb_pipeendpoint(pipe)];

		if (unlikely(!ep)) {
			spin_unlock(&data->fb_urb_lock);
			return -EINVAL;
		}

		pipe = (pipe & ~(3 << 30)) | (PIPE_INTERRUPT << 30);
		usb_fill_int_urb(data->fb_urb, usb_dev, pipe, data->fb_vbitmap,
				 G13_VBITMAP_SIZE, g13_fb_urb_completion, NULL,
				 ep->desc.bInterval);
		data->fb_urb->context = data;
		data->fb_urb->actual_length = 0;

		retval = usb_submit_urb(data->fb_urb, GFP_NOIO);
		if (unlikely(retval < 0)) {
			/*
			 * We need to unlock the framebuffer urb lock since
			 * the urb submission failed and therefore
			 * g13_fb_urb_completion() won't be called.
			 */
			spin_unlock(&data->fb_urb_lock);
			return retval;
		}
	} else {
		schedule_delayed_work(&data->fb_info->deferred_work,
				      data->fb_defio.delay);
	}

	return retval;
}

Thanks,

-- 

Rick


WARNING: multiple messages have this Message-ID (diff)
From: "Rick L. Vinyard, Jr." <rvinyard-qcTL/1vZYtiVc3sceRu5cw@public.gmane.org>
To: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Cc: "Bruno Prémont"
	<bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>,
	"Jiri Kosina" <jkosina-AlSwsSmVLrQ@public.gmane.org>,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Nicu Pavel" <npavel-VxACSXvuqMTQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 1/3] picolcd: driver for PicoLCD HID device
Date: Wed, 24 Feb 2010 14:44:53 -0700	[thread overview]
Message-ID: <ffb352764fc5a0da5cca6f3da7fc2603.squirrel@intranet.cs.nmsu.edu> (raw)
In-Reply-To: <201002241927.53532.oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>


Oliver Neukum wrote:
> Am Mittwoch, 24. Februar 2010 17:00:49 schrieb Bruno Prémont:
>> +static int picolcd_raw_event(struct hid_device *hdev,
>> +               struct hid_report *report, u8 *raw_data, int size)
>> +{
>> +       struct picolcd_data *data = hid_get_drvdata(hdev);
>> +       char hexdata[25];
>> +       int i;
>> +
>> +       if (data == NULL)
>> +               return 1;
>> +
>> +       for (i = 0; i < sizeof(hexdata) / 2; i++)
>> +               sprintf(hexdata+2*i, "%02hhx", raw_data[i]);
>> +       if (size >= sizeof(hexdata)/2) {
>> +               hexdata[sizeof(hexdata)-4] = '.';
>> +               hexdata[sizeof(hexdata)-3] = '.';
>> +               hexdata[sizeof(hexdata)-2] = '.';
>> +               hexdata[sizeof(hexdata)-1] = '\0';
>> +       } else
>> +               hexdata[size*2] = '\0';
>> +
>> +       switch (report->id) {
>> +       case REPORT_KEYPAD:
>> +               if (size == 3 && raw_data[0] == 0x11 &&
>> data->input_keys) {
>> +                       return picolcd_raw_keypad(hdev, report,
>> raw_data+1, size-1);
>> +               } else {
>> +                       dbg_hid(PICOLCD_NAME " unsupported key event (%d
>> bytes): 0x%s\n", size, hexdata);
>> +                       break;
>> +               }
>> +               break;
>> +       case REPORT_VERSION:
>> +               if (size == 3)
>> +                       dev_info(&hdev->dev, "Firmware version is
>> %hd.%hd\n", raw_data[1], raw_data[2]);
>> +
>> +               spin_lock(&data->lock);
>
> If I recall correctly raw_event is called in interrupt. As you take a
> spinlock here,
> the lock in code not called in interrupt must disable interrupts, or you
> may
> deadlock.
>

The issue, as I understand it is that non-interrupt code may obtain the
lock and then the interrupt code is executed... hence the deadlock and the
need to use spin_lock_irqsave() and spin_unlock_irqrestore().

If that is correct, is there any problem with the following approach?

The key difference is the replacement of spin_lock() with spin_trylock()
such that if the non-interrupt code has already obtained the lock, the
interrupt will not deadlock but instead take the else path and schedule a
framebuffer update at the next interval.

static void g13_fb_urb_completion(struct urb *urb)
{
	struct g13_data *data = urb->context;
	spin_unlock(&data->fb_urb_lock);
}

static int g13_fb_send(struct hid_device *hdev)
{
	struct usb_interface *intf;
	struct usb_device *usb_dev;
	struct g13_data *data = hid_get_g13data(hdev);

	struct usb_host_endpoint *ep;
	unsigned int pipe;
	int retval = 0;

	/*
	 * Try and lock the framebuffer urb to prevent access if we have
	 * submitted it. If we can't lock it we'll have to delay this update
	 * until the next framebuffer interval.
	 *
	 * Fortunately, we already have the infrastructure in place with the
	 * framebuffer deferred I/O driver to schedule the delayed update.
	 */
	if (likely(spin_trylock(&data->fb_urb_lock))) {
		/* Get the usb device to send the image on */
		intf = to_usb_interface(hdev->dev.parent);
		usb_dev = interface_to_usbdev(intf);

		pipe = usb_sndintpipe(usb_dev, 0x02);

		ep = usb_dev->ep_out[usb_pipeendpoint(pipe)];

		if (unlikely(!ep)) {
			spin_unlock(&data->fb_urb_lock);
			return -EINVAL;
		}

		pipe = (pipe & ~(3 << 30)) | (PIPE_INTERRUPT << 30);
		usb_fill_int_urb(data->fb_urb, usb_dev, pipe, data->fb_vbitmap,
				 G13_VBITMAP_SIZE, g13_fb_urb_completion, NULL,
				 ep->desc.bInterval);
		data->fb_urb->context = data;
		data->fb_urb->actual_length = 0;

		retval = usb_submit_urb(data->fb_urb, GFP_NOIO);
		if (unlikely(retval < 0)) {
			/*
			 * We need to unlock the framebuffer urb lock since
			 * the urb submission failed and therefore
			 * g13_fb_urb_completion() won't be called.
			 */
			spin_unlock(&data->fb_urb_lock);
			return retval;
		}
	} else {
		schedule_delayed_work(&data->fb_info->deferred_work,
				      data->fb_defio.delay);
	}

	return retval;
}

Thanks,

-- 

Rick

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Rick L. Vinyard, Jr." <rvinyard@cs.nmsu.edu>
To: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Cc: "Bruno Prémont"
	<bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>,
	"Jiri Kosina" <jkosina-AlSwsSmVLrQ@public.gmane.org>,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Nicu Pavel" <npavel-VxACSXvuqMTQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 1/3] picolcd: driver for PicoLCD HID device
Date: Wed, 24 Feb 2010 21:44:53 +0000	[thread overview]
Message-ID: <ffb352764fc5a0da5cca6f3da7fc2603.squirrel@intranet.cs.nmsu.edu> (raw)
In-Reply-To: <201002241927.53532.oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>


Oliver Neukum wrote:
> Am Mittwoch, 24. Februar 2010 17:00:49 schrieb Bruno Prémont:
>> +static int picolcd_raw_event(struct hid_device *hdev,
>> +               struct hid_report *report, u8 *raw_data, int size)
>> +{
>> +       struct picolcd_data *data = hid_get_drvdata(hdev);
>> +       char hexdata[25];
>> +       int i;
>> +
>> +       if (data = NULL)
>> +               return 1;
>> +
>> +       for (i = 0; i < sizeof(hexdata) / 2; i++)
>> +               sprintf(hexdata+2*i, "%02hhx", raw_data[i]);
>> +       if (size >= sizeof(hexdata)/2) {
>> +               hexdata[sizeof(hexdata)-4] = '.';
>> +               hexdata[sizeof(hexdata)-3] = '.';
>> +               hexdata[sizeof(hexdata)-2] = '.';
>> +               hexdata[sizeof(hexdata)-1] = '\0';
>> +       } else
>> +               hexdata[size*2] = '\0';
>> +
>> +       switch (report->id) {
>> +       case REPORT_KEYPAD:
>> +               if (size = 3 && raw_data[0] = 0x11 &&
>> data->input_keys) {
>> +                       return picolcd_raw_keypad(hdev, report,
>> raw_data+1, size-1);
>> +               } else {
>> +                       dbg_hid(PICOLCD_NAME " unsupported key event (%d
>> bytes): 0x%s\n", size, hexdata);
>> +                       break;
>> +               }
>> +               break;
>> +       case REPORT_VERSION:
>> +               if (size = 3)
>> +                       dev_info(&hdev->dev, "Firmware version is
>> %hd.%hd\n", raw_data[1], raw_data[2]);
>> +
>> +               spin_lock(&data->lock);
>
> If I recall correctly raw_event is called in interrupt. As you take a
> spinlock here,
> the lock in code not called in interrupt must disable interrupts, or you
> may
> deadlock.
>

The issue, as I understand it is that non-interrupt code may obtain the
lock and then the interrupt code is executed... hence the deadlock and the
need to use spin_lock_irqsave() and spin_unlock_irqrestore().

If that is correct, is there any problem with the following approach?

The key difference is the replacement of spin_lock() with spin_trylock()
such that if the non-interrupt code has already obtained the lock, the
interrupt will not deadlock but instead take the else path and schedule a
framebuffer update at the next interval.

static void g13_fb_urb_completion(struct urb *urb)
{
	struct g13_data *data = urb->context;
	spin_unlock(&data->fb_urb_lock);
}

static int g13_fb_send(struct hid_device *hdev)
{
	struct usb_interface *intf;
	struct usb_device *usb_dev;
	struct g13_data *data = hid_get_g13data(hdev);

	struct usb_host_endpoint *ep;
	unsigned int pipe;
	int retval = 0;

	/*
	 * Try and lock the framebuffer urb to prevent access if we have
	 * submitted it. If we can't lock it we'll have to delay this update
	 * until the next framebuffer interval.
	 *
	 * Fortunately, we already have the infrastructure in place with the
	 * framebuffer deferred I/O driver to schedule the delayed update.
	 */
	if (likely(spin_trylock(&data->fb_urb_lock))) {
		/* Get the usb device to send the image on */
		intf = to_usb_interface(hdev->dev.parent);
		usb_dev = interface_to_usbdev(intf);

		pipe = usb_sndintpipe(usb_dev, 0x02);

		ep = usb_dev->ep_out[usb_pipeendpoint(pipe)];

		if (unlikely(!ep)) {
			spin_unlock(&data->fb_urb_lock);
			return -EINVAL;
		}

		pipe = (pipe & ~(3 << 30)) | (PIPE_INTERRUPT << 30);
		usb_fill_int_urb(data->fb_urb, usb_dev, pipe, data->fb_vbitmap,
				 G13_VBITMAP_SIZE, g13_fb_urb_completion, NULL,
				 ep->desc.bInterval);
		data->fb_urb->context = data;
		data->fb_urb->actual_length = 0;

		retval = usb_submit_urb(data->fb_urb, GFP_NOIO);
		if (unlikely(retval < 0)) {
			/*
			 * We need to unlock the framebuffer urb lock since
			 * the urb submission failed and therefore
			 * g13_fb_urb_completion() won't be called.
			 */
			spin_unlock(&data->fb_urb_lock);
			return retval;
		}
	} else {
		schedule_delayed_work(&data->fb_info->deferred_work,
				      data->fb_defio.delay);
	}

	return retval;
}

Thanks,

-- 

Rick


  reply	other threads:[~2010-02-24 21:45 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-20 23:10 [Patch 0/3] backlight Bruno Prémont
2010-02-20 23:10 ` Bruno Prémont
2010-02-20 23:18 ` [PATCH 2/3] backlight: mark struct backlight_ops const Bruno Prémont
2010-02-20 23:18   ` Bruno Prémont
2010-02-20 23:18   ` Bruno Prémont
2010-02-20 23:18   ` Bruno Prémont
     [not found]   ` <20100221001851.673db863-hY15tx4IgV39zxVx7UNMDg@public.gmane.org>
2010-02-22 19:35     ` Mike Frysinger
2010-02-22 19:35       ` Mike Frysinger
2010-02-22 19:35       ` Mike Frysinger
2010-02-22 19:35       ` Mike Frysinger
2010-02-26 11:56   ` [PATCH] " Bruno Prémont
2010-02-26 11:56     ` Bruno Prémont
2010-02-20 23:20 ` [PATCH 1/3] backlight: Add backlight_device parameter to check_fb Bruno Prémont
2010-02-20 23:20   ` Bruno Prémont
2010-02-24 16:00   ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Bruno Prémont
2010-02-24 16:00     ` Bruno Prémont
2010-02-24 16:00     ` Bruno Prémont
2010-02-24 16:01     ` [PATCH 2/3] hid: add suspend/resume hooks for hid drivers Bruno Prémont
2010-02-25  4:19       ` Oliver Neukum
2010-02-25 10:12         ` Bruno Prémont
2010-02-24 16:01     ` [PATCH 3/3] hid-picolcd: make use of new suspend/resume hooks Bruno Prémont
2010-02-24 16:01       ` Bruno Prémont
2010-02-24 18:27     ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Oliver Neukum
2010-02-24 18:27       ` Oliver Neukum
2010-02-24 18:27       ` Oliver Neukum
2010-02-24 21:44       ` Rick L. Vinyard, Jr. [this message]
2010-02-24 21:44         ` Rick L. Vinyard, Jr.
2010-02-24 21:44         ` Rick L. Vinyard, Jr.
2010-02-25  4:11         ` Oliver Neukum
2010-02-25  4:11           ` Oliver Neukum
2010-02-25 11:00         ` Jiri Kosina
2010-02-25 11:00           ` Jiri Kosina
2010-02-25 15:34           ` Rick L. Vinyard, Jr.
2010-02-25 15:34             ` Rick L. Vinyard, Jr.
2010-02-26  8:12             ` Dmitry Torokhov
2010-02-26  8:12               ` Dmitry Torokhov
2010-02-25 11:07     ` Jiri Kosina
2010-02-25 11:07       ` Jiri Kosina
2010-02-25 11:07       ` Jiri Kosina
2010-02-25 11:32       ` Bruno Prémont
2010-02-25 11:32         ` Bruno Prémont
2010-02-25 11:32         ` Bruno Prémont
2010-02-25 15:18         ` Jiri Kosina
2010-02-25 15:18           ` Jiri Kosina
2010-02-25 15:18           ` Jiri Kosina
2010-02-25 15:29           ` Bruno Prémont
2010-02-25 15:29             ` Bruno Prémont
2010-03-13 19:39           ` Bruno Prémont
2010-03-13 19:39             ` Bruno Prémont
2010-03-13 21:35             ` Alan Stern
2010-03-13 21:35               ` Alan Stern
2010-03-13 22:13               ` [PATCH] hid: Register debugfs entries before adding device Bruno Prémont
2010-03-13 22:13                 ` Bruno Prémont
2010-03-15 13:48                 ` Jiri Kosina
2010-02-25 17:52         ` [PATCH 1/3] picolcd: driver for PicoLCD HID device Rick L. Vinyard, Jr.
2010-02-25 17:52           ` Rick L. Vinyard, Jr.
2010-02-25 17:52           ` Rick L. Vinyard, Jr.
2010-02-26  8:15       ` Dmitry Torokhov
2010-02-26  8:15         ` Dmitry Torokhov
2010-02-26  8:15         ` Dmitry Torokhov
2010-03-03  6:04     ` Pavel Machek
2010-03-03  6:04       ` Pavel Machek
2010-02-26 11:53   ` [PATCH] backlight: Add backlight_device parameter to check_fb Bruno Prémont
2010-02-26 11:53     ` Bruno Prémont
2010-02-20 23:28 ` [PATCH 3/3] backlight: fix missing/incomplete registration failure handling Bruno Prémont
2010-02-20 23:28   ` [PATCH 3/3] backlight: fix missing/incomplete registration failure Bruno Prémont
2010-02-21  8:04   ` [PATCH 3/3] backlight: fix missing/incomplete registration failure handling Harald Welte
2010-02-21 13:35   ` Thadeu Lima de Souza Cascardo
2010-02-21 13:35     ` [PATCH 3/3] backlight: fix missing/incomplete registration Thadeu Lima de Souza Cascardo
2010-02-24 15:33     ` [PATCH 3/3] backlight: fix missing/incomplete registration failure handling Anisse Astier
2010-02-24 15:33       ` [PATCH 3/3] backlight: fix missing/incomplete registration Anisse Astier
2010-02-26 11:59   ` [PATCH] backlight, classmate-laptop: fix missing registration failure handling Bruno Prémont
2010-02-26 16:20     ` Thadeu Lima de Souza Cascardo
2010-02-26 16:32       ` Matthew Garrett
2010-02-26 16:45         ` Richard Purdie
2010-02-26 22:25           ` Bruno Prémont
2010-02-26 12:02   ` [PATCH] backlight, appledisplay: fix incomplete " Bruno Prémont
2010-02-26 12:04   ` [PATCH] backlight, blackfin: fix missing " Bruno Prémont
2010-02-26 12:04     ` [PATCH] backlight, blackfin: fix missing registration failure Bruno Prémont
2010-02-26 12:17   ` [PATCH] backlight, msi-laptop, msi-wmi: fix incomplete registration failure handling Bruno Prémont
2010-02-26 12:20   ` [PATCH] backlight, panasonic-laptop: " Bruno Prémont

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ffb352764fc5a0da5cca6f3da7fc2603.squirrel@intranet.cs.nmsu.edu \
    --to=rvinyard@cs.nmsu.edu \
    --cc=bonbons@linux-vserver.org \
    --cc=jkosina@suse.cz \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=npavel@ituner.com \
    --cc=oliver@neukum.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.