On Wed, Nov 28, 2012 at 2:33 PM, Michael Kerrisk wrote:
> On Thu, May 3, 2012 at 2:29 AM, Kay Sievers wrote:
>> From: Kay Sievers
> [...]
>> case SYSLOG_ACTION_SIZE_UNREAD:
>> - error = log_end - log_start;
>> +
On Wed, Nov 28, 2012 at 5:37 PM, Linus Torvalds
wrote:
> On Wed, Nov 28, 2012 at 8:22 AM, Kay Sievers wrote:
>> On Wed, Nov 28, 2012 at 2:33 PM, Michael Kerrisk
>> wrote:
>>
>>> On a 2.6.31 system, immediately after SYSLOG_ACTION_READ_CLEAR, a
>>> SYSLOG_
On Wed, 2012-11-28 at 17:49 +0100, Kay Sievers wrote:
> On Wed, Nov 28, 2012 at 5:37 PM, Linus Torvalds
> wrote:
> > On Wed, Nov 28, 2012 at 8:22 AM, Kay Sievers wrote:
> >> On Wed, Nov 28, 2012 at 2:33 PM, Michael Kerrisk
> >> wrote:
> >>
>
On Thu, Nov 29, 2012 at 2:18 PM, Michael Kerrisk (man-pages)
wrote:
> On Wed, Nov 28, 2012 at 6:51 PM, Kay Sievers wrote:
>> Before:
>> syslog(SYSLOG_ACTION_SIZE_UNREAD, 0, 0) = 286965
>> syslog(SYSLOG_ACTION_READ_CLEAR, "<12>"..., 100) = 24000
>
On Thu, Nov 29, 2012 at 2:37 PM, Michael Kerrisk (man-pages)
wrote:
> On Thu, Nov 29, 2012 at 2:28 PM, Kay Sievers wrote:
>> On Thu, Nov 29, 2012 at 2:18 PM, Michael Kerrisk (man-pages)
>> wrote:
>>> On Wed, Nov 28, 2012 at 6:51 PM, Kay Sievers wrote:
>&
On Thu, Nov 29, 2012 at 3:18 PM, Michael Kerrisk (man-pages)
wrote:
> So, just to be clear: you better not apply your patch; it might break
> something ;-).
Sounds good to me. :)
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
On Thu, Nov 29, 2012 at 11:46 PM, Joe Perches wrote:
> It's still a scheduling issue with Kay and Jan's patches.
> Does anyone have any idea if/when those patches are going in?
I was expecting that Jan rebases the patches incorporating
the latest fix. Jan?
It should not hold back anything else
On Wed, Mar 20, 2013 at 10:11 PM, William Hubbs wrote:
> On Wed, Mar 20, 2013 at 02:03:20AM -0500, Rob Landley wrote:
>> On 03/19/2013 07:20:17 PM, William Hubbs wrote:
>> > On Tue, Mar 19, 2013 at 04:17:11PM -0700, H. Peter Anvin wrote:
>> > > On 03/19/2013 03:28 PM, William Hubbs wrote:
>> > > >
On Mon, Feb 25, 2013 at 11:12 PM, Greg KH wrote:
> Hm, I thought we were frowning apon running binaries from udev rules
> these days, especially ones that might have big consequences (like
> resizing a disk image) like this.
>
> Kay, am I right?
We removed most of them from the default setups, y
On Mon, Feb 25, 2013 at 11:43 PM, Greg KH wrote:
> On Mon, Feb 25, 2013 at 11:39:52PM +0100, Kay Sievers wrote:
>> On Mon, Feb 25, 2013 at 11:12 PM, Greg KH wrote:
>>
>> > Hm, I thought we were frowning apon running binaries from udev rules
>> > these days, es
On Tue, Feb 12, 2013 at 12:15 AM, Josh Boyer wrote:
> Using /dev/pstore as a mount point for the pstore filesystem is slightly
> awkward. We don't normally mount filesystems in /dev/ and the /dev/pstore
> file isn't created automatically by anything. While this method will
> still work, we can c
On Sun, Mar 17, 2013 at 2:38 PM, Alex Williamson
wrote:
> I'm assuming that the device only breaks because udevadm is dumping the
> full I/O port register space of the device and that if an actual driver
> was interacting with it through this interface that it would work. Who
> knows how many dev
On Sun, Mar 17, 2013 at 3:20 PM, Myron Stowe wrote:
> On Sun, 2013-03-17 at 15:00 +0100, Kay Sievers wrote:
>> On Sun, Mar 17, 2013 at 2:38 PM, Alex Williamson
>> wrote:
>> > I'm assuming that the device only breaks because udevadm is dumping the
>> > full
On Sun, Mar 17, 2013 at 3:36 PM, Myron Stowe wrote:
> On Sun, 2013-03-17 at 15:29 +0100, Kay Sievers wrote:
>> On Sun, Mar 17, 2013 at 3:20 PM, Myron Stowe wrote:
>> > On Sun, 2013-03-17 at 15:00 +0100, Kay Sievers wrote:
>> >> On Sun, Mar 17, 2013 at 2:38 PM
On Fri, Sep 14, 2012 at 9:29 PM, Tejun Heo wrote:
> On Fri, Sep 14, 2012 at 09:58:30AM -0400, Vivek Goyal wrote:
>> I am little concerned about above and wondering how systemd and libvirt
>> will interact and behave out of the box.
>>
>> Currently systemd does not create its own hierarchy under bl
On Wed, Oct 3, 2012 at 12:12 AM, Greg KH wrote:
> Mauro, what version of udev are you using that is still showing this
> issue?
>
> Kay, didn't you resolve this already? If not, what was the reason why?
It's the same in the current release, we still haven't wrapped our
head around how to fix it
On Wed, Oct 3, 2012 at 6:57 PM, Greg KH wrote:
>> It's the same in the current release, we still haven't wrapped our
>> head around how to fix it/work around it.
>
> Ick, as this is breaking people's previously-working machines, shouldn't
> this be resolved quickly?
Nothing really "breaks", It's
On Wed, Oct 3, 2012 at 10:39 PM, Linus Torvalds
wrote:
> On Wed, Oct 3, 2012 at 12:50 PM, Greg KH wrote:
>>>
>>> Ok, like this?
>>
>> This looks good to me. Having udev do firmware loading and tieing it to
>> the driver model may have not been such a good idea so many years ago.
>> Doing it this
On Wed, Oct 3, 2012 at 11:05 PM, Greg KH wrote:
> As for the firmware path, maybe we should
> change that to be modified by userspace (much like /sbin/hotplug was) in
> a proc file so that distros can override the location if they need to.
If that's needed, a CONFIG_FIRMWARE_PATH= with the array
On Thu, Oct 4, 2012 at 12:58 AM, Linus Torvalds
wrote:
> That said, there's clearly enough variation here that I think that for
> now I won't take the step to disable the udev part. I'll do the patch
> to support "direct filesystem firmware loading" using the udev default
> paths, and that hopeful
On Tue, Oct 23, 2012 at 8:36 AM, David Miller wrote:
> From: Doug Goldstein
> Date: Mon, 22 Oct 2012 00:53:57 -0500
>
>> Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
>> applications that query network information via udev to identify vlans
>> instead of using strrchr().
On Mon, Oct 8, 2012 at 9:56 PM, Kay Sievers wrote:
> On Mon, Oct 8, 2012 at 9:54 PM, "Jan H. Schönherr"
>>> Jan,
>>> any updates, did you try something else?
>>> Or should we merge the first version for now?
>>
>> I'm working on it,
On Mon, Sep 9, 2013 at 5:58 PM, Tom Gundersen wrote:
> Hi Konrad,
>
> The above commit (c70bda9 in mainline) doesn't appear to work for me.
> I.e., depmod does not create an entry in modules.devname and hence no
> device node is created on boot.
>
> If I understand correctly, you'd also need to cr
On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern wrote:
> Where is MODULE_SOFTDEP defined? It isn't mentioned in any .h files in
> my kernel tree.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7cb14ba75d57910cc4b62115dd5db7bd83c93684
Kay
--
To unsubscribe from this list:
On Thu, Aug 29, 2013 at 4:13 PM, Jan Kaluza wrote:
> Add new SCM type called SCM_CGROUP to send "cgroup_path" in SCM.
> This is useful for journald (systemd logging daemon) to get additional context
> with each log line received using UNIX socket.
>
> Signed-off-by: Jan Kaluza
In many cases it's
On Fri, Sep 28, 2012 at 4:56 PM, Kay Sievers wrote:
> On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
>> Given that I'm able to fix the racing case, would you be in favor of
>> this approach, or should we stick to the earlier version?
>
> I'm open
On Mon, Oct 8, 2012 at 9:54 PM, "Jan H. Schönherr"
wrote:
> Am 08.10.2012 21:24, schrieb Kay Sievers:
>> On Fri, Sep 28, 2012 at 4:56 PM, Kay Sievers wrote:
>>> On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
>>
>>>> Given that I
On Wed, 2012-11-14 at 00:12 +0100, Jan H. Schönherr wrote:
> Hi Greg, hi Kay, and all other interested people.
>
> This series aims at cleaning up and fixing some bugs around printk().
> Patches 9 and 11 might require some discussion, see below.
This is how current git looks like:
[1.062953]
On Thu, Nov 15, 2012 at 10:22 PM, "Jan H. Schönherr"
wrote:
> Am 15.11.2012 17:05, schrieb Kay Sievers:
>> This with all your patches applied:
>> [1.032804] input: ImExPS/2 Generic Explorer Mouse as
>> /devices/platform/i8042/serio1/input/input2
>>
On Sat, Nov 17, 2012 at 1:27 AM, Greg Kroah-Hartman
wrote:
> On Fri, Nov 16, 2012 at 04:20:16PM -0800, Kees Cook wrote:
>> Since devtmpfs is writable, make the default noexec nosuid as well. This
>> protects from the case of a privileged process having an arbitrary file
>> write flaw and an argume
On Wed, Jul 3, 2013 at 1:57 AM, Thomas Gleixner wrote:
> On Sun, 30 Jun 2013, Lennart Poettering wrote:
>> On 29.06.2013 05:05, Tim Hockin wrote:
>> > But that's not my point. It seems pretty easy to make this cgroup
>> > management (in "native mode") a library that can have either a thin
>> > ve
On Sat, Jun 29, 2013 at 10:53 PM, Sami Kerola wrote:
> BTW having a way to measure effect of suspend/resume could lead to a
> way to fix time time distortion.
> Perhaps there is better alternative to fix user space programs.
> Unfortunately I do not have either knowledge, or imagination, to come
On Mon, Jul 29, 2013 at 1:54 PM, Hidehiro Kawai
wrote:
> Also, I heard about the discussion
> at the kernel summit 2 years ago. According to the article of LWN,
> it seems that Linus objected your approach (i.e. adding random bit as
> message ID). Were there some agreements on this issue at the
On Fri, Aug 2, 2013 at 6:28 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Fri, Aug 02, 2013 at 09:04:44AM -0700, Andy Lutomirski wrote:
>> CONFIG_FW_LOADER_USER_HELPER=y
> Do you need this? Unsetting this should help.
>
> """This option enables / disables the invocation of user-helper
> (e.g. udev)
On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki wrote:
> After a recent change present in 3.11-rc1 there is a driver, called processor,
> that can be bound to the CPU devices whose sysfs directories are located under
> /sys/devices/system/cpu/. A side effect of this is that, after the driver
On Sat, Jul 20, 2013 at 1:47 PM, Kay Sievers wrote:
> On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki wrote:
>
>> After a recent change present in 3.11-rc1 there is a driver, called
>> processor,
>> that can be bound to the CPU devices whose sysfs directories are l
On Thu, Jul 25, 2013 at 5:03 PM, Dave Hansen wrote:
> On 07/25/2013 04:14 AM, KY Srinivasan wrote:
>> As promised, I have sent out the patches for (a) an implementation of an
>> in-kernel API
>> for onlining and a consumer for this API. While I don't know the exact
>> reason why the
>> user mod
On Wed, Jul 3, 2013 at 3:46 AM, Hidehiro Kawai
wrote:
> This patch series adds hash values of printk format strings into
> each line of /dev/kmsg outputs as follows:
>
> 6,154,325061,-,b7db707c@kernel/smp.c:554;Brought up 4 CPUs
/dev/kmsg is to a certain degree a kernel ABI. Having sourc
On Sat, Aug 10, 2013 at 11:00 PM, Tom Gundersen wrote:
> It would be simple enough to add an udev rule to just print 'ignoring
> firmware event' to the logs.
This and I guess:
SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"
would also just cancel the request at the same time without an
On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman
wrote:
> On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote:
>> Kay tells me the most appropriate place to expose workqueues to
>> userland would be /sys/devices/virtual/workqueues/WQ_NAME which is
>> symlinked to /sys/bus/workqueue/devices
On Mon, Mar 4, 2013 at 8:51 AM, Eric W. Biederman wrote:
>
> Modify the request_module to prefix the file system type with "fs-"
> and add aliases to all of the filesystems that can be built as modules
> to match.
>
> A common practice is to build all of the kernel code and leave code
> that is no
On Sat, Apr 6, 2013 at 7:58 PM, Greg KH wrote:
> On Sat, Apr 06, 2013 at 06:45:12PM +0100, Al Viro wrote:
>> On Sat, Apr 06, 2013 at 10:26:12AM -0700, Greg KH wrote:
>>
>> > Why not? "closed" systems, like Android and other embedded systems,
>> > have "assigned" uid and gid values that never chan
On Wed, May 8, 2013 at 6:26 PM, Takashi Iwai wrote:
> At Thu, 9 May 2013 00:07:17 +0800,
> Ming Lei wrote:
>> On Wed, May 8, 2013 at 2:56 PM, Takashi Iwai wrote:
>> > Hi,
>> >
>> > this is a series of patches for the issue we faced in the firmware
>> > loader code during debugging the problem wi
Hey,
what's the intention of:
e90c83f757fffdacec8b3c5eee5617dcc038338f ?
x86: Select HAS_PERSISTENT_CLOCK on x86
It unconditionally sets:
HAS_PERSISTENT_CLOCK
but:
RTC_SYSTOHC
got a depends on !HAS_PERSISTENT_CLOCK
This makes it impossible to sync the system time from the RTC on x86.
Wha
On Wed, Apr 24, 2013 at 4:43 AM, John Stultz wrote:
> On 04/23/2013 06:34 PM, Kay Sievers wrote:
>>
>> Hey,
>>
>> what's the intention of:
>>e90c83f757fffdacec8b3c5eee5617dcc038338f ?
>>x86: Select HAS_PERSISTENT_CLOCK on x86
>>
>
On Wed, Apr 24, 2013 at 5:19 AM, John Stultz wrote:
> On 04/23/2013 08:05 PM, Kay Sievers wrote:
>>
>> On Wed, Apr 24, 2013 at 4:43 AM, John Stultz
>> wrote:
>>>
>>> On 04/23/2013 06:34 PM, Kay Sievers wrote:
>>&
On Wed, Apr 24, 2013 at 5:33 AM, Kay Sievers wrote:
> Also:
> $ cat /sys/class/rtc/rtc0/hctosys
> 0
> always carried "1", and this now breaks setups which expect an
> automatically created symlink /dev/rtc to the actual "system rtc".
We used to do t
On Wed, Apr 24, 2013 at 6:07 PM, John Stultz wrote:
> So summarizing the above, because as much as I'm aware, its always been
> redundant and unnecessary on x86. Thus being able at build time to mark it
> as unnecessary was attractive, since it reduced the code paths running at
> suspend/resume.
On Wed, Apr 24, 2013 at 6:30 PM, John Stultz wrote:
>> Until the above commits we always needed:
>>CONFIG_RTC_HCTOSYS=y
>>CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
>> to get the system time correctly initialized at bootup on x86.
> So... always needed to get system time correctly initialized? I'm
On Tue, Apr 9, 2013 at 6:33 PM, Kees Cook wrote:
> On Tue, Apr 9, 2013 at 8:48 AM, Josh Boyer wrote:
>> The dmesg_restrict sysctl currently covers the syslog method for access
>> dmesg, however /dev/kmsg isn't covered by the same protections. Most
>> people haven't noticed because util-linux dme
On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote:
> Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config,
> which enables some minor compile time optimization to avoid
> uncessary code in mostly the suspend/resume path could cause
> problems for userland.
>
>
On Wed, Apr 24, 2013 at 8:55 PM, John Stultz wrote:
> On 04/24/2013 11:41 AM, Kay Sievers wrote:
>>
>> On Wed, Apr 24, 2013 at 8:32 PM, John Stultz
>> wrote:
>>>
>>> Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config,
>>> which enabl
On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote:
> Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config,
> which enables some minor compile time optimization to avoid
> uncessary code in mostly the suspend/resume path could cause
> problems for userland.
>
>
On Wed, Apr 24, 2013 at 11:51 PM, Josh Boyer wrote:
>> In the daemon case, it's nice to be able to drop privileges after
>> setting up resources. The past was open /proc/kmsg with CAP_SYS_ADMIN,
>> then drop CAP_SYS_ADMIN and keep reading. Then later CAP_SYS_LOG was
>> introduced. So if a daemon
On Thu, Apr 25, 2013 at 9:11 AM, Alexander Holler wrote:
> Hmm, I thought RTC_SYSTOHC was there to update the used RTC clock with the
> time from NTP (and liked that).
That seems to have the nice self-explaining name CONFIG_GENERIC_CMOS_UPDATE. :)
> Therefor I don't understand why it is
> redun
On Thu, Apr 25, 2013 at 8:33 PM, Jason Gunthorpe
wrote:
> So, my conclusion is nobody with a RTC looking for space savings, will
> disable CONFIG_RTC, which means we can safely rely on
> CONFIG_RTC_SYSTOHC to do this work. To that end, I would encourage
> everyone who sets CONFIG_GENERIC_CMOS_UPDA
On Wed, Apr 24, 2013 at 8:55 PM, John Stultz wrote:
>> FWIW, in the light of the original change, I've just removed the
>> /dev/rtc creation from the default udev rules now, so that thing will
>> be phased out in the future.
>
> Is that actually wanted? What happens to applications that use /dev/
On Fri, Mar 8, 2013 at 12:31 AM, Greg Kroah-Hartman
wrote:
> On Tue, Mar 05, 2013 at 12:43:27PM -0800, Tejun Heo wrote:
>> On Sun, Mar 03, 2013 at 07:42:31AM +0100, Kay Sievers wrote:
>> > On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman
>> > wrote:
>> >
On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman
wrote:
> On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote:
>> Hey, guys.
>>
>> On Fri, Mar 08, 2013 at 01:04:25AM +0100, Kay Sievers wrote:
>> > > Sorry for the delay, I'm at a conference all this
On Sun, Mar 10, 2013 at 6:24 PM, Greg Kroah-Hartman
wrote:
> On Sun, Mar 10, 2013 at 06:00:18PM +0100, Kay Sievers wrote:
>> On Sun, Mar 10, 2013 at 5:45 PM, Greg Kroah-Hartman
>> wrote:
>> > On Sun, Mar 10, 2013 at 04:57:02AM -0700, Tejun Heo wrote:
>> >> H
On Thu, Aug 2, 2012 at 9:46 PM, Vikram Pandita wrote:
> From: Vikram Pandita
>
> Introduce config option to enable CPU id reporting for printk() calls.
>
> Its sometimes very useful to have printk also print the CPU Identifier
> that executed the call. This has helped to debug various SMP issues
On Fri, Aug 3, 2012 at 1:50 AM, Pandita, Vikram wrote:
> On Thu, Aug 2, 2012 at 1:08 PM, Kay Sievers wrote:
>> How is that supposed to be useful?
>>
>> The prefix is added while exporting data from the kmsg buffer, which
>> is just the CPU that *reads* the data f
On Fri, Aug 3, 2012 at 11:36 AM, Pandita, Vikram wrote:
> On Fri, Aug 3, 2012 at 2:32 AM, Venu Byravarasu
> wrote:
>> As having Macro locally in the file of interest would serve the purpose,
>> Why to change the printk code?
>
> As stated, the logic followed is exactly similar to well proven an
On Fri, Aug 3, 2012 at 11:43 AM, Nikunj A Dadhania
wrote:
> On Fri, 3 Aug 2012 02:16:18 -0700, Vikram Pandita
> wrote:
>> +static size_t print_cpuid(u8 cpuid, char *buf)
>> +{
>> +
>> + if (!printk_cpuid)
>> + return 0;
>> +
>> + if (!buf)
>> + return 4;
>> +
>
On Fri, Aug 3, 2012 at 11:56 AM, Pandita, Vikram wrote:
> On Fri, Aug 3, 2012 at 2:48 AM, Kay Sievers wrote:
>> On Fri, Aug 3, 2012 at 11:36 AM, Pandita, Vikram
>> wrote:
>>> On Fri, Aug 3, 2012 at 2:32 AM, Venu Byravarasu
>>> wrote:
>>
>>>&
On Thu, Aug 23, 2012 at 5:16 PM, Ming Lei wrote:
> On Tue, Aug 21, 2012 at 1:34 PM, Ming Lei wrote:
>> I found that udev 182 doesn't response for the request_firmware in
>> module_probe path until 30sec later after the 'ADD' event of firmware
>> device, but no such problem in udev175, sounds lik
On Feb 18, 2008 1:59 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Feb 2008 14:08:53 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>
> > Booting without SYSFS fills dmesg like this
>
> Does the system normally boot without sysfs? Surprised.
>
>
> > [ cut here ]--
On Feb 18, 2008 9:06 PM, Stephen Hemminger
<[EMAIL PROTECTED]> wrote:
> On Mon, 18 Feb 2008 19:42:25 + (GMT)
> Chris Rankin <[EMAIL PROTECTED]> wrote:
>
> > --- Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > > > > sysfs: duplicate filename 'bridge' can not be created
> > > > > WARNING: at fs/
On Tue, 2008-02-19 at 15:03 +0300, Alexey Dobriyan wrote:
> On Tue, Feb 19, 2008 at 09:19:25AM +0100, Kay Sievers wrote:
> > On Feb 18, 2008 1:59 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > On Fri, 15 Feb 2008 14:08:53 +0300 Alexey Dobriyan <[EMA
On Tue, Feb 19, 2008 at 9:47 AM, Kay Sievers <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 9:06 PM, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > On Mon, 18 Feb 2008 19:42:25 + (GMT)
> > Chris Rankin <[EMAIL PROTECTED]> wrote:
> >
> > >
On Mon, Jul 9, 2012 at 8:03 PM, Dave Jones wrote:
> I noticed that the format of the oom-killer output seems to have changed, and
> now it spews stuff like..
>
> [49461.758070] lowmem_reserve[]:
> [49461.758071] 0
> [49461.758071] 2643
> [49461.758071] 3878
> [49461.758072] 3878
> [49461.75807
On Mon, 2012-07-09 at 20:27 +0200, Kay Sievers wrote:
> On Mon, Jul 9, 2012 at 8:03 PM, Dave Jones wrote:
> > I noticed that the format of the oom-killer output seems to have changed,
> > and
> > now it spews stuff like..
> >
> > [49461.758070] lowmem
On Mon, Jul 9, 2012 at 10:44 PM, Joe Perches wrote:
>> > That single patch doesn't apply cleanly to Linus'
>> > 8c84bf4166a4698296342841a549bbee03860ac0
>> >
>> > What else is necessary?
>> >
>> > Your tree seems to have a collection of random patches.
>> >
>> > It might be useful to clone Linus'
On Mon, Jul 9, 2012 at 11:42 PM, Joe Perches wrote:
> On Sun, 2012-07-08 at 19:55 +0200, Kay Sievers wrote:
>
>> At the same time the CPU#2 prints the same warning with a continuation
>> line, but the buffer from CPU#1 can not be flushed to the console, nor
>> can the con
On Tue, Jul 10, 2012 at 12:29 AM, Joe Perches wrote:
> On Tue, 2012-07-10 at 00:10 +0200, Kay Sievers wrote:
>> On Mon, Jul 9, 2012 at 11:42 PM, Joe Perches wrote:
>> > On Sun, 2012-07-08 at 19:55 +0200, Kay Sievers wrote:
>> >
>> >> At the same time t
Hey Joe,
what do you think this?
It would make composing continuation lines at the caller side entirely
race-free, and it might fit into the usual pattern.
The more interesting thing, this would allow us to completely race-free
use the dev_printk() calls with continuation content, which we shoul
On Wed, 2012-07-11 at 12:33 +0200, Kay Sievers wrote:
> Hey Joe,
>
> what do you think of this?
>
> It would make composing continuation lines at the caller side entirely
> race-free, and it might fit into the usual pattern.
>
> The more interesting thing, this would all
On Wed, Jul 11, 2012 at 5:01 PM, Joe Perches wrote:
> On Wed, 2012-07-11 at 12:33 +0200, Kay Sievers wrote:
> Interesting idea, perhaps workable, but it has
> a few defects I can see.
>
> It works for most uses, but it doesn't work for
> when there are multiple funct
On Wed, Jul 11, 2012 at 5:30 PM, Joe Perches wrote:
> On Wed, 2012-07-11 at 17:14 +0200, Kay Sievers wrote:
>> On Wed, Jul 11, 2012 at 5:01 PM, Joe Perches wrote:
> []
>> There are _many_ cases the console lock is held, and we don't print
>> stuff immediately out
On Wed, Jul 11, 2012 at 6:55 PM, Joe Perches wrote:
> On Wed, 2012-07-11 at 17:48 +0200, Kay Sievers wrote:
>> On Wed, Jul 11, 2012 at 5:30 PM, Joe Perches wrote:
>> > Well, I think the malloc costs are pretty low
>> > and could devolve pretty easily when OOM.
>&g
On Wed, Jul 11, 2012 at 7:51 PM, Joe Perches wrote:
> On Wed, 2012-07-11 at 19:25 +0200, Kay Sievers wrote:
>> > If your solution is just for the dev_ messages
>> > (ie: with vprintk_emit descriptors), then it's not
>> > too ugly.
>>
>> Yeah, I th
On Thu, Jul 12, 2012 at 2:54 AM, Dave Jones wrote:
> On Mon, Jul 09, 2012 at 08:48:51PM +0200, Kay Sievers wrote:
> > It looks fine here with the above mentioned patch:
>
> Now that that patch is in Linus tree, I've hit what's probably a different
> case.
> L
On Thu, Jul 12, 2012 at 4:05 PM, Dave Jones wrote:
> On Thu, Jul 12, 2012 at 03:52:17PM +0200, Kay Sievers wrote:
> > On Thu, Jul 12, 2012 at 2:54 AM, Dave Jones wrote:
> > > On Mon, Jul 09, 2012 at 08:48:51PM +0200, Kay Sievers wrote:
> >
> > > > It look
On Thu, Jul 12, 2012 at 7:11 PM, Linus Torvalds
wrote:
> On Thu, Jul 12, 2012 at 7:05 AM, Dave Jones wrote:
>>
>> I've seen it a few times, always with the soft lockup trace.
>
> I bet it's because you have tons of modules, and the line ends up
> being *really* long. And overflows LOG_LINE_MAX. I
On Thu, 2012-07-12 at 20:25 +0200, Kay Sievers wrote:
> On Thu, Jul 12, 2012 at 7:11 PM, Linus Torvalds
> wrote:
> > On Thu, Jul 12, 2012 at 7:05 AM, Dave Jones wrote:
> >>
> >> I've seen it a few times, always with the soft lockup trace.
> >
> > I
On Tue, Nov 20, 2012 at 9:42 PM, Kees Cook wrote:
> Since devtmpfs is writable, make the default noexec,nosuid as well. This
> protects from the case of a privileged process having an arbitrary file
> write flaw and an argumentless arbitrary execution (i.e. it would lack
> the ability to run "moun
On Wed, Nov 21, 2012 at 3:52 PM, Greg Kroah-Hartman
wrote:
> On Wed, Nov 21, 2012 at 02:44:31PM +, Grant Likely wrote:
>> The "platform_bus" (note: not platform_bus_type) only exists as an empty
>> directory to put platform devices into. However, it really doesn't make
>> sense to segregate al
On Thu, Nov 22, 2012 at 11:44 AM, Jan Schmidt wrote:
> I'm currently debugging something in btrfs in good old printk style,
> generating
> around 10MB/min. I'm seeing /proc/kmsg returning eof on a blocking read (and,
> side note, syslog-ng won't reopen it, effectively stopping logging kernel
> me
On Thu, Nov 22, 2012 at 10:20 PM, Grant Likely
wrote:
> On Thu, Nov 22, 2012 at 7:17 PM, Kay Sievers wrote:
>> On Wed, Nov 21, 2012 at 3:52 PM, Greg Kroah-Hartman
>> wrote:
>>> If the devices don't show up under platform/ where are they going to be
>>>
On Thu, Sep 27, 2012 at 12:33 AM, "Jan H. Schönherr"
wrote:
> Am 26.09.2012 23:15, schrieb Greg Kroah-Hartman:
>> On Wed, Sep 26, 2012 at 07:58:45PM +0200, Jan H. Schönherr wrote:
>>> Against v3.6-rc7, only lightly tested.
>>
>> Well, against linux-next and highly tested would be best. It's a bit
On Thu, Sep 27, 2012 at 5:46 PM, "Jan H. Schönherr"
wrote:
> Am 27.09.2012 15:39, schrieb Kay Sievers:
>> It is a flag that we have not been able to merge a continuation line
>> in the buffer, because we had a race with another thread, or the
>> console lock w
On Fri, Sep 28, 2012 at 10:25 AM, Jan H. Schönherr
wrote:
>> If really, really everything passes through vprintk_emit()
>> then we could keep all info about the previous message
>> there and definitely decide whether the current message continues
>> the previous one.
>>
>> Then, we wouldn't need
On Fri, Sep 28, 2012 at 4:49 PM, "Jan H. Schönherr"
wrote:
> Am 28.09.2012 16:34, schrieb Kay Sievers:
>> On Fri, Sep 28, 2012 at 10:25 AM, Jan H. Schönherr
>> The current behaviour has the advantage, that non-cont users will not
>> race against a cont user (whi
On Fri, Jul 6, 2012 at 12:46 PM, Kay Sievers wrote:
> On Fri, Jul 6, 2012 at 5:47 AM, Michael Neuling wrote:
>
>>> 4,89,24561;NIP: c0048164 LR: c0048160 CTR:
>>> 4,90,24576;REGS: c0007e59fb50 TRAP: 0700 Tainted: GW
On Fri, Jul 6, 2012 at 10:30 PM, Linus Torvalds
wrote:
> Kay, this needs to be fixed.
>
> Suggested fix: just use the 'seq_printf()' interfaces, which do the
> proper buffering, and allow any size reads of various packetized data.
I'll have a look.
> Of course, I'd also suggest that whoever was
On Sat, Jul 7, 2012 at 12:05 AM, Jukka Ollila wrote:
> And I did a little digging. According to the Debian package tracking
> system[1] it would seem that the _stable_ distro carries a version
> that doesn't do the dd shuffling at all and probably runs its klogd as
> root, reading /proc/kmsg direc
On Sat, 2012-07-07 at 23:19 +0200, Kay Sievers wrote:
> On Fri, Jul 6, 2012 at 10:30 PM, Linus Torvalds
> wrote:
> > Kay, this needs to be fixed.
> >
> > Suggested fix: just use the 'seq_printf()' interfaces, which do the
> > proper buffering, and allow a
On Fri, Jul 6, 2012 at 7:55 PM, Greg KH wrote:
> On Fri, Jul 06, 2012 at 08:45:44PM +0300, Jukka Ollila wrote:
>> Hello,
>>
>> A few days ago I filed a kernel regression report concerning a change
>> in /proc/kmsg behaviour with short reads:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=44211
On Sun, Jul 8, 2012 at 2:59 PM, Alan Cox wrote:
>> The patch will not fix the underlying problem, but just make it behave
>> more like it was and allow partial message reads. This is a years old
>> problem, the net is full of bugreports of stuff going wrong with
>> running dd bs=1 on /proc/kmsg. I
On Sat, 2012-07-07 at 07:04 +1000, Michael Neuling wrote:
> Whole kmsg below.
I guess I have an idea now what's going on.
> 4,47,0;WARNING: at
> /scratch/mikey/src/linux-ozlabs/arch/powerpc/sysdev/xics/xics-common.c:105
> 4,51,0;MSR: 90021032 CR: 2442 XER: 2200
> 4,54,0;TASK =
1 - 100 of 428 matches
Mail list logo
