+
+/*
+ * In case of failure of any of these tests, memory corruption is almost
+ * guarranteed; allowing the boot to continue means risking to corrupt
+ * also any filesystem/block device accessed write mode.
+ * Therefore, BUG_ON() is used, when testing.
+ */
+
+
I like the explanation;
+
+/*
+ * In case of failure of any of these tests, memory corruption is almost
+ * guarranteed; allowing the boot to continue means risking to corrupt
+ * also any filesystem/block device accessed write mode.
+ * Therefore, BUG_ON() is used, when testing.
+ */
+
+
I like the explanation;
On 26/02/18 21:12, Matthew Wilcox wrote:
[...]
> panic() halts the kernel
> BUG_ON() kills the thread
> WARN_ON() just prints messages
>
> Now, if we're at boot time and we're still executing code from the init
> thread, killing init is equivalent to halting the kernel.
>
> The question is,
On 26/02/18 21:12, Matthew Wilcox wrote:
[...]
> panic() halts the kernel
> BUG_ON() kills the thread
> WARN_ON() just prints messages
>
> Now, if we're at boot time and we're still executing code from the init
> thread, killing init is equivalent to halting the kernel.
>
> The question is,
On Mon, Feb 26, 2018 at 08:00:26PM +0200, Igor Stoppa wrote:
> On 26/02/18 19:46, J Freyensee wrote:
> > That's a good question. Based upon those articles, 'yes'. But it seems
> > like a 'darned-if-you-do, darned-if-you-don't' question as couldn't you
> > also corrupt a mounted filesystem by
On Mon, Feb 26, 2018 at 08:00:26PM +0200, Igor Stoppa wrote:
> On 26/02/18 19:46, J Freyensee wrote:
> > That's a good question. Based upon those articles, 'yes'. But it seems
> > like a 'darned-if-you-do, darned-if-you-don't' question as couldn't you
> > also corrupt a mounted filesystem by
On 26/02/18 19:46, J Freyensee wrote:
>
>
> On 2/26/18 4:11 AM, Igor Stoppa wrote:
>>
>> On 24/02/18 00:42, J Freyensee wrote:
+ locations[action->location] = gen_pool_alloc(pool, action->size);
+ BUG_ON(!locations[action->location]);
>>> Again, I'd think it through if you really
On 26/02/18 19:46, J Freyensee wrote:
>
>
> On 2/26/18 4:11 AM, Igor Stoppa wrote:
>>
>> On 24/02/18 00:42, J Freyensee wrote:
+ locations[action->location] = gen_pool_alloc(pool, action->size);
+ BUG_ON(!locations[action->location]);
>>> Again, I'd think it through if you really
On 2/26/18 4:11 AM, Igor Stoppa wrote:
On 24/02/18 00:42, J Freyensee wrote:
+ locations[action->location] = gen_pool_alloc(pool, action->size);
+ BUG_ON(!locations[action->location]);
Again, I'd think it through if you really want to use BUG_ON() or not:
On 2/26/18 4:11 AM, Igor Stoppa wrote:
On 24/02/18 00:42, J Freyensee wrote:
+ locations[action->location] = gen_pool_alloc(pool, action->size);
+ BUG_ON(!locations[action->location]);
Again, I'd think it through if you really want to use BUG_ON() or not:
On 24/02/18 00:42, J Freyensee wrote:
>
>> +locations[action->location] = gen_pool_alloc(pool, action->size);
>> +BUG_ON(!locations[action->location]);
>
> Again, I'd think it through if you really want to use BUG_ON() or not:
>
> https://lwn.net/Articles/13183/
>
On 24/02/18 00:42, J Freyensee wrote:
>
>> +locations[action->location] = gen_pool_alloc(pool, action->size);
>> +BUG_ON(!locations[action->location]);
>
> Again, I'd think it through if you really want to use BUG_ON() or not:
>
> https://lwn.net/Articles/13183/
>
+ locations[action->location] = gen_pool_alloc(pool, action->size);
+ BUG_ON(!locations[action->location]);
Again, I'd think it through if you really want to use BUG_ON() or not:
https://lwn.net/Articles/13183/
https://lkml.org/lkml/2016/10/4/1
Thanks,
Jay
+ locations[action->location] = gen_pool_alloc(pool, action->size);
+ BUG_ON(!locations[action->location]);
Again, I'd think it through if you really want to use BUG_ON() or not:
https://lwn.net/Articles/13183/
https://lkml.org/lkml/2016/10/4/1
Thanks,
Jay
14 matches
Mail list logo
